Re: Large Commit Issues! 10Mbps Upload cap on a Gigabit LAN

Probably a disk IO issue, on your Win2K3 server can you run the perfmon tool
(Start->Administratiion Tools -> Peformance) when you do the co/ci and
tell us
what you see under view report for -

Memory pages/s
Physical disk, Avg Disk Q length

While you are at it, you may want to fill in the info Samay requested in
the last email.

When you say "any other tranfer" is > 450 Mbps, what kind of transfer is
that ? I mean SVN
will need to create the transaction file when ci'ing and unless you have
super fast disk (Ultra 320
SCSI etc) writing at sustained 450 Mbps is unlikely. The 10 Mbps disk
IO on commit on the other hand
is also low unless you have very slow disks. What's the disk specs like
? The other apps may be reading
buffer cache and not going to physical disk at all so that caveat
applies, but after a checkout buffer
cache should be warm and you should see faster transfer for checkouts.

Regards,

-- 
Rahul Bhargava,
Subversion,CVS Solutions
WANdisco,Inc.
Pleasanton, CA
http://www.wandisco.com
Ahmed Reza wrote:
> Thanks for getting back to me.  But I've looked at every other 
> possible bottle neck.  Anyother transfer from the server to client is 
> blazing fast (at least 450+Mbps).  I had it down to just the PC & 
> server talking, and there is no way I could get a checkout done where 
> more than 20Mbps bandwidth use (I was checking the bandwidth usage as 
> soon as I did a checkout or checkin).  I'm pretty sure it's subversion 
> itself, doing some sort of memory stuff, where a buffer size is set or 
> something...  Both my PC & Server are running on Window (PC: XP SP2 
> Server: Win'03).  It's just wierd!  It takes me a long time (>50mins) 
> to do a ~5-10GB checkin/checkout.  That's just waaay too slow when I 
> have nearly a TerraByte worth of data that I need to put under version 
> control.  I read some other people were having similar issues with 
> checkin/checkout of large files, I mean 10-20Mbps is great, just not 
> so great on where you have a 1Gb connection with no bottlenecks.  Once 
> again, thanks for any input on this matter.  I am a passionate 
> advocate for open-source software, and if I would love to put show off 
> a subversion system to some of the microsoft groupie execs, so please 
> help!
>  
> Regards,
> Ahmed
>
>  
> On 4/22/06, *Samay* <getafix123@hotmail.com 
> <mailto:getafix123@hotmail.com>> wrote:
>
>     Transfer speed also depends on
>     a) server specs -> processor, memory
>     b) bus speed
>     c) any IRQ sharing (e.g. Eth0 & Drive Controller sharing same
>     IRQ-- ouch!!)
>     d) speed of drives & raid controller, raid config
>     e) server load (processes in wait stage?)
>     f) operating system & configuration.
>     g) and MTU (jumbo frames?) on the network itself
>      
>     of course least common denominator of the server & cliebt
>     capability defines the over all speed u may get. Care to share
>     details above?
>      
>     regards
>      
>     Shirish
>
>         ----- Original Message -----
>         *From:* Ahmed Reza <mailto:ahmedrezat@gmail.com>
>         *To:* users@subversion.tigris.org
>         <mailto:users@subversion.tigris.org>
>         *Sent:* Sunday, April 23, 2006 3:06 AM
>         *Subject:* Large Commit Issues! 10Mbps Upload cap on a Gigabit LAN
>
>          
>
>             Hi, I'm running into an issue that nobody seems to know a
>             heck of  a lot about.  I'm moving a whole bunch of files
>             from an old repository system (RCS) to SVN (i.e 80,000+
>             files, ~60GB).  However, checking in is virtually
>             impossible.   I have a Gigabit connection to the server
>             and all other data transfers are blazing fast except for
>             SVN which caps at 10Mbps uploading to the server and
>             20Mbps when I'm checking out.  I would really, really
>             appreciate any help on this subject as I have googled this
>             for hours to no avail.
>              
>             Thanks,
>             Ahmed
>
>
>
This email and any attachments may contain private, confidential and privileged material for the sole use ofthe intended recipient. If you are not the intended recipient, please immediately delete this email and any attachments.