[p4] Performance question

[Martin Ellison]

We would like some advice. We would like to know if any other Perforce
users are in a similar situation to us and can offer any advice. In
particular, we would like to know whether any Perforce users are currently
working in high-latency environments such as slow WAN links and VPN over
the Internet successfully? If so, who?
Our Perforce server is situated in Sydney, Australia and we have a branch
office in Hyderabad, India with one Perforce user. She is experiencing
some problems accessing Perforce and we would like to know if there is
anything that could be done to improve her access.
We are running 99.2 on NT4 as P4S. Our users here in Sydney are running
normally and memory usage on the server appears to be normal.
The user in India is running P4Win connected over a leased line. On
attempting a large sync, she reported that she was "stuck on the same file
for more than half an hour" . She reports that p4 -V "comes up very fast"
and p4 info "comes up very fast ( 10 secs maybe)".
We are wondering if there are any Perforce parameters that could be
modified to allow for the high latency of the connection.
We raised this with Perforce support and they suggested checking the
[no]compress option on the client. As it happened, the user had nocompress
set and when she changed that setting to compress it did improve
performance. However, we are wondering if there are any tuneable
parameters (documented or undocumented) that may help (whether Perforce,
TCP/IP or whatever).
Regards,
Martin Ellison
Perforce analyst
bullant Technology Pty Ltd
delivering zero friction computing

[Peter Theunis]

Hmm..To check out if this is a network problem, try to ping and traceroute
between your office and your user. If it's slow on the network level,
there's nothing you could do about it, except
changing ISP. Compress should improve the performance if both sides (client
& server) are fast machines; less information to send over the wires. I
guess you're tunneling over SSH.

We have our HQ in California and one remote coder working from Sydney,
Australia. His commands on the server and his sync's are really fast.

Good luck,

Peter
-----Original Message-----
From: Martin Ellison [mailto:***@bullant.com]
Sent: Wednesday, August 23, 2000 5:36 PM
To: 'perforce-***@perforce.com'
Subject: [p4] Performance question

We would like some advice. We would like to know if any other Perforce
users are in a similar situation to us and can offer any advice. In
particular, we would like to know whether any Perforce users are currently
working in high-latency environments such as slow WAN links and VPN over
the Internet successfully? If so, who?
Our Perforce server is situated in Sydney, Australia and we have a branch
office in Hyderabad, India with one Perforce user. She is experiencing
some problems accessing Perforce and we would like to know if there is
anything that could be done to improve her access.
We are running 99.2 on NT4 as P4S. Our users here in Sydney are running
normally and memory usage on the server appears to be normal.
The user in India is running P4Win connected over a leased line. On
attempting a large sync, she reported that she was "stuck on the same file
for more than half an hour" . She reports that p4 -V "comes up very fast"
and p4 info "comes up very fast ( 10 secs maybe)".
We are wondering if there are any Perforce parameters that could be
modified to allow for the high latency of the connection.
We raised this with Perforce support and they suggested checking the
[no]compress option on the client. As it happened, the user had nocompress
set and when she changed that setting to compress it did improve
performance. However, we are wondering if there are any tuneable
parameters (documented or undocumented) that may help (whether Perforce,
TCP/IP or whatever).
Regards,
Martin Ellison
Perforce analyst
bullant Technology Pty Ltd
delivering zero friction computing

_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Chuck Karish]

Post by Peter Theunis
Sent: Wednesday, August 23, 2000 5:36 PM
Subject: [p4] Performance question

We would like some advice. We would like to know if any other Perforce
users are in a similar situation to us and can offer any advice. In
particular, we would like to know whether any Perforce users are currently
working in high-latency environments such as slow WAN links and VPN over
the Internet successfully? If so, who?

We have users at three remote sites on our corporate WAN and
numerous VPN users, on both fast links and slow. Remote users
don't have any problems with Perforce except slow file transfer
times over slow lines. Turning on compression does help a lot.
We don't see unusual pauses in transmission.

Post by Peter Theunis

Our Perforce server is situated in Sydney, Australia and we have a branch
office in Hyderabad, India with one Perforce user. She is experiencing
some problems accessing Perforce and we would like to know if there is
anything that could be done to improve her access.
We are running 99.2 on NT4 as P4S. Our users here in Sydney are running
normally and memory usage on the server appears to be normal.
The user in India is running P4Win connected over a leased line. On
attempting a large sync, she reported that she was "stuck on the same file
for more than half an hour" . She reports that p4 -V "comes up very fast"
and p4 info "comes up very fast ( 10 secs maybe)".

Should she have been "stuck"? How big was the file that was being
transferred, and how long was the transfer "stuck"? What time was the
problem noticed? When p4 transfers stall it's usually because
there's a deadlock: two user requests try to lock the same part of the
depot. Did this happen during a backup?

Is the user's client software version 99.2? Locking was cleaned up in the
99.2 server to cut down on contention. I don't know whether any of these
fixes require the latest client, but it won't hurt to make sure. Check the
minor release level of your server. If 'p4 info' tells you that p4d is at
change 13307, upgrade it right away.

Post by Peter Theunis

We are wondering if there are any Perforce parameters that could be
modified to allow for the high latency of the connection.
We raised this with Perforce support and they suggested checking the
[no]compress option on the client. As it happened, the user had nocompress
set and when she changed that setting to compress it did improve
performance. However, we are wondering if there are any tuneable
parameters (documented or undocumented) that may help (whether Perforce,
TCP/IP or whatever).

Make sure that the user has a clean TCP/IP connection, with an acceptable
error/retransmission rate.

Post by Peter Theunis

Regards,
Martin Ellison
Perforce analyst
bullant Technology Pty Ltd
delivering zero friction computing

_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user
_______________________________________________
http://maillist.perforce.com/mailman/listinfo/perforce-user

Received: from eis-msg-014.jpl.nasa.gov (eis-msg-014.jpl.nasa.gov [137.78.160.158])
by frankenrouter.perforce.com (8.9.3/8.9.1) with ESMTP id RAA08326
for <perforce-***@perforce.com>; Wed, 23 Aug 2000 17:47:45 -0700 (PDT)
Received: from [137.78.16.194] (mjordan.jpl.nasa.gov [137.78.16.194])
by eis-msg-014.jpl.nasa.gov (8.9.3/8.9.3) with ESMTP id RAA01514
for <perforce-***@perforce.com.>; Wed, 23 Aug 2000 17:47:38 -0700 (PDT)
Mime-Version: 1.0
X-Sender: ***@mail1.jpl.nasa.gov
Message-Id: <v04210106b5ca2036f69a@[137.78.16.194]>
Date: Wed, 23 Aug 2000 17:48:21 -0700
To: perforce-***@perforce.com
From: Ted Drain <***@jpl.nasa.gov>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [p4] Only the owner can change a label?
Sender: perforce-user-***@perforce.com
Errors-To: perforce-user-***@perforce.com
X-BeenThere: perforce-***@perforce.com
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Discuss Perforce with other users <perforce-user.perforce.com>

Hi all,

Is there any way to allow any user (or group) to use the labelsync
command? It seems like only the owner of the label can use labelsync
on the label.

This seems a little strange since any user can edit the label to
change the owner to themselves, then call labelsync.

So, I try to say:

1: p4 labelsync -l SomeLabel //depot//somefile.txt
Can't modify label 'SomeLabel' owned by 'somebody'.

2: p4 label SomeLabel
(edit the field Owner to be me)

3: p4 labelsync -l SomeLabel //depot//somefile.txt

So the owner field doesn't provide any protection, yet causes me to
do extra work. Am I missing a command or an options somewhere?

Thanks
Ted
Ted Drain Jet Propulsion Laboratory ***@jpl.nasa.gov

[a***@coremedia-ag.com]

For exceptional cases (e.g. initial setup), you could wrap up a client
workspace in a .zip archive, ftp it, unpack it in the client workspace, and use
p4 flush to convince the perforce server that your remote user has the latest
version. See the entry for p4 flush in the command reference. (assuming of
course that ftp can transfer the bits a few percent faster than perforce due to
reduced protocol overhead, which need not be the case - maybe you will just
need a more stable network connection).

Regards,
Axel.

The user in India is running P4Win connected over a leased line. On
attempting a large sync, she reported that she was "stuck on the same file
for more than half an hour" . She reports that p4 -V "comes up very fast"
and p4 info "comes up very fast ( 10 secs maybe)".

10 seconds is not really fast for a p4 info, is it?

--
Axel Wienberg - Software Engineer
***@coremedia-ag.com - fon +49.40.325587.509 fax .199
CoreMedia AG - www.coremedia-ag.com
Düsternstraße 3, 20355 Hamburg, Germany

[Andrew Dalgleish]

Date: Thu, 24 Aug 2000 10:36:20 +1000
charset="iso-8859-1"
Subject: [p4] Performance question

We raised this with Perforce support and they suggested checking the
[no]compress option on the client. As it happened, the user had

nocompress

set and when she changed that setting to compress it did improve
performance. However, we are wondering if there are any tuneable
parameters (documented or undocumented) that may help (whether

Perforce,

TCP/IP or whatever).

[Andrew Dalgleish]

We use Perforce between Melbourne and various parts of USA + Canada and
find the performance acceptible.
(Untill someone checks in a 100MB binary without telling anyone. :-)

A few suggestions:
* If you are using SSH make sure that you dont have both SSH and
perforce trying to do compression.
* Check the tcp "max path MTU discovery" settings for your client,
server and firewalls.
(Search the MS KB for details.
Sometimes SSH tunnelling via a non-windows box is *faster* than a direct
connection because of this.)
* Try doing a "p4 sync" from a different client OS.
* Does the server also have a remote depot pointing somewhere else?
This can cause a big performance hit.

Has anyone tried installing a perforce server with a remote depot on
each remote client?
This would only provide read-only access, but I am wondering if it would
be any faster.
Which server stores the client state, the local server or the remote
depot?

Regards,
Andrew Dalgleish

[Lawrence You]

We would like some advice. We would like to know if any other Perforce users
are in a similar situation to us and can offer any advice. In particular, we
would like to know whether any Perforce users are currently working in
high-latency environments such as slow WAN links and VPN over the Internet
successfully? If so, who?

Some of our users have been using slow links, from 33K modems up to
128K ISDN and we also regularly use VPN software to access our server
which is behind our firewall.

Our users are located in the U.S. and abroad and the modem-based
performance has been adequate. We just set up equipment to bridge a
remote office using IPsec and ran an experiment here in the U.S.,
on-site, using a simple bandwidth shaper. We haven't tried to
investigate the impact of high-latency on performance.

I don't know the amount of latency our users experience from outside,
but I'm pretty sure whenever I've tried it using remote connections
over the VPN, it has been less than 700ms and more like 300ms max.

Our Perforce server is situated in Sydney, Australia and we have a branch
office in Hyderabad, India with one Perforce user. She is experiencing some
problems accessing Perforce and we would like to know if there is anything
that could be done to improve her access.
We are running 99.2 on NT4 as P4S. Our users here in Sydney are running
normally and memory usage on the server appears to be normal.
The user in India is running P4Win connected over a leased line. On
attempting a large sync, she reported that she was "stuck on the same file
for more than half an hour" . She reports that p4 -V "comes up very fast"
and p4 info "comes up very fast ( 10 secs maybe)".
We are wondering if there are any Perforce parameters that could be modified
to allow for the high latency of the connection.
We raised this with Perforce support and they suggested checking the
[no]compress option on the client. As it happened, the user had nocompress
set and when she changed that setting to compress it did improve
performance. However, we are wondering if there are any tuneable parameters
(documented or undocumented) that may help (whether Perforce, TCP/IP or
whatever).
Regards,
Martin Ellison
Perforce analyst
bullant Technology Pty Ltd
delivering zero friction computing

In the past when I worked in a remote office, I discovered that some
of the issues that appear to be related to bandwidth and latency were
actually from dropped packets. We used ping/traceroute and determined
that sometimes 50% of the packets were getting dropped. The company's
headquarters were hosted through a highly saturated network; later
they switched to UUNet and the number of dropped packets went down to
a neglible amount and the throughput became significantly better. At
the time we were using 128K (2B) ISDN in our remote office. You could
probably try similar experiments with ping and see where, if any,
packets are getting dropped.

By the way, if you want to try to simulate a low-bandwidth link,
here's an easy method:

Get "ip_relay" from here:

http://www.stewart.com.au/ip_relay/

And set it up on your Perforce server (or another host) using
"ip_relay.pl 1667:perforce.yourdomain.com:1666". We use Linux and it
just ran out of the box. On NT you'd probably have to have Perl
running but there isn't any reason you couldn't run the script on a
nearby Unix box that would forward for you.

Connect your clients using p4/p4win. Make sure they point to port 1667.

In ip_relay, type "set bandwidth 2000" to simulate 2000 bytes per
second. You should be able to see the client slow down. You can then
try to use "set bandwidth 0" (no limit) and the client will speed up.
I don't know anything about the perl script (I just found it on
freshmeat.net), but it was sufficient for us to experiment with low
bandwidth.

-Lawrence

[Kearney, Greg]

Using perforce over vpn has been ok for us. For normal operation that is
sync, checkin, submit. Of course, large syncs ( 200MB to 1GB ) are painful
but generally better or equal to ftp.

This helped a little over vpn:

p4 client: use compress switch (only helps if the file is "compress-able").


gk

-----Original Message-----
From: Martin Ellison [mailto:***@bullant.com]
Sent: Wednesday, August 23, 2000 4:52 PM
To: 'perforce-***@perforce.com'
Cc: Bruce Hatcher; Alka Yamarti
Subject: [p4] Performance question


We would like some advice. We would like to know if any other Perforce users
are in a similar situation to us and can offer any advice. In particular, we
would like to know whether any Perforce users are currently working in
high-latency environments such as slow WAN links and VPN over the Internet
successfully? If so, who?

Our Perforce server is situated in Sydney, Australia and we have a branch
office in Hyderabad, India with one Perforce user. She is experiencing some
problems accessing Perforce and we would like to know if there is anything
that could be done to improve her access.

We are running 99.2 on NT4 as P4S. Our users here in Sydney are running
normally and memory usage on the server appears to be normal.

The user in India is running P4Win connected over a leased line. On
attempting a large sync, she reported that she was "stuck on the same file
for more than half an hour" . She reports that p4 -V "comes up very fast"
and p4 info "comes up very fast ( 10 secs maybe)".

We are wondering if there are any Perforce parameters that could be modified
to allow for the high latency of the connection.

We raised this with Perforce support and they suggested checking the
[no]compress option on the client. As it happened, the user had nocompress
set and when she changed that setting to compress it did improve
performance. However, we are wondering if there are any tuneable parameters
(documented or undocumented) that may help (whether Perforce, TCP/IP or
whatever).

Regards,
Martin Ellison
Perforce analyst
bullant Technology Pty Ltd
E-mail: ***@bullant.com

delivering zero friction computing



_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user