When I transfer a large file, like an opensuse iso image from the server to the desktop or vice versa, the speed start pretty good (about 40MB/s) it stays there for about 30 seconds, then drops off to about 6MB/s.
The Windows XP machine in the same network doesn’t do this with the same file.
All machines, including server tower, have the Intel Pro GT1000 network card, and all the network is Cat5e/6 and gigabit switches.
Wondering why the Opensuse machines are doing this, and can it be fixed.
When you transfer the first few blocks of the file, the recipient hasn’t written them to disk yet. Eventually it has to write something to disk and then if blocks are coming in faster than disk writes can be done on average, the rate will be throttled back. Something similar applies for the sending side.
In addition, initially the number of blocks and the elapsed times are small, thus giving very rough and inaccurate instantaneous speeds when divided. It’s the settled state rate of transfer that is a better indicator of the real speed.
Yes I have tested and timed. Average sustained speed of WindowsXP machine moving an opensuse64bit iso image to the server and back is around 44MB/s. The two Opensuses (one 64bit) are both at 8MB/s. This is calculating 4.3G divided by how much time it takes.
Still, I agree. The link may not be realized if the NICs are not
setting the proper mode (100 vs. 1000 Mbit).
Good luck.
ken yap wrote:
| Then there is something wrong because 44MB/s is more like what a gigabit
| link should sustain, and 8MB feels more like a 100Mb/s link.
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
When you transfer the first few blocks of the file, the recipient hasn’t written them to disk yet. Eventually it has to write something to disk and then if blocks are coming in faster than disk writes can be done on average, the rate will be throttled back. Something similar applies for the sending side.
In addition, initially the number of blocks and the elapsed times are small, thus giving very rough and inaccurate instantaneous speeds when divided. It’s the settled state rate of transfer that is a better indicator of the real speed.
This is really what I was saying earlier too. Not really my field, but surely it like the water out of a pipe story - it doesn’t matter how much you push thru one end - you can only get out as much as the narrowest point will allow.
So you are saying - if you put a stop watch to it (not going of what it’s telling you) - the windows machine shifts it THAT much quicker!
If so, then there does seem to be a problem. But as I say, not my field really.
Hope you get it sorted Heeter
Heeter wrote:
> I did what swerdna asked me to put into my smb.conf, and it knocked out
> my mouse and keyboard.
When I saw your original post, I didn’t believe that smb.conf could affect a
mouse and keyboard. Please open a terminal and enter the command
dmesg | less
This will bring up the log file for the current boot and page it for you. You
can move up/down in the file with pg up/down, the up/down arrow keys or get a
new page with the space bar. When you are done looking, type a q to quilt. Look
over the output for anything related to your non-functioning keyboard or mouse.
You can post any sections that look suspicious. The system is pretty chatty, so
we usually do not want everyting posted.
But it looks like exactly the last line you posted. I did put it in the global section. I still haven’t been able to fix that machine yet. I am not going to try it on this one, need this one running.
What is the difference between them, They look the same to me.
>
> It’s an outside chance, but easy to add or remove. Open the samba config
> file in a root editor with e.g. tis command in KDE:
>> kdesu kwrite /etc/samba/smb.conf
> or for Gnome this will work:
>> gnomesu gedit /etc/samba/smb.conf
>
> Just copy this text into the [global] section as a discrete line
> amongst the other lines:> socket options = TCP_NODELAY SO_SNDBUF=8192
> SO_RCVBUF=8192 Reboot. Test the transfer speed again. If it works – good.
> If it doesn’t – take the line out again.
>
> No harm – might help
> (and I promise I took the rodent toxins out of the line this time)
>
>
Swerdna;
“socket options” are now generally not recommended for the smb.conf. Most
of the modern kernels are much better at optimizing these parameters. Most
find that setting these in smb.conf actually reduces performance.
