| Author |
Message |
|
graysky
|
 Posted: Sat Dec 09, 2006 6:24 am |
|
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
Been trying to enable either 4k or 9k jumbo frames in my knoppmyth box. I did a:
Code: # ifconfig eth0 mtu 4088
Which then reports the change in my mtu size. Problem is that both mythweb and samba stop working unless I set the mtu back to 1500. My switch supports up to 9k jumbo frames as do the NICs in my boxes. ssh works just fine.
Anyone know what I'm doing wrong?
_________________
Retired KM user (R4 - R6.04); friend to LH users.
|
|
| Top |
|
 |
|
tjc
|
Posted: Sat Dec 09, 2006 11:01 am |
|
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
I'm using jumbo frames (9000) without any problems here, but my LAN is all Linux and all the machines are set to the same MTU. Then again, I haven't seen any problems with stuff going to the outside world through the old 100Mbit firewall router...
BTW - Don't know if it helps but I've got this chunk of shell code as part of my custom setup that gets run after upgrades:
Code: # enable jumbo frames
/sbin/ifconfig eth0 mtu 9000
grep 'MTU=9000' /etc/sysconfig/network-scripts/ifcfg-eth0 >/dev/null ||
echo 'MTU=9000' >>/etc/sysconfig/network-scripts/ifcfg-eth0
grep 'mtu 9000' /etc/init.d/bootmisc.sh ||
cat <<EOF >>/etc/init.d/bootmisc.sh
# enable jumbo frames
/sbin/ifconfig eth0 mtu 9000
EOF
|
|
| Top |
|
|
|
graysky
|
Posted: Sat Dec 09, 2006 1:21 pm |
|
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
THanks for the info... I dunno what my problem is with jumbo frames. My switch supports them, yet I can't get anything to work (2 LINUX boxes and a win32 box).
Code: ifconfig eth0 mtu 4088
Works to set the mtu size to 4088 or 4000 or 9000 but neither of the linux boxes can ping each other. The win32 box can ping either of the linux boxes and even ssh into them but nothing else works to/from them (ftp, samba, nfs). It's odd.
_________________
Retired KM user (R4 - R6.04); friend to LH users.
|
|
| Top |
|
|
|
RacerX
|
Posted: Sat Dec 09, 2006 4:45 pm |
|
|
Joined: Sun Sep 05, 2004 7:06 pm
Posts: 690
|
|
My guess that that your router does not know what a jumbo frame is literally? So it has a hard time figuring out what to do with the packet.
Moreover, it is a mystery to me why TJC does not have the same problem with his router once he tried to accees the internet. I would expect that there would be problems with slow web page loads and maybe even nothing comes up. The idea of jumbo frames sounds good since our video files are huge and the original frame size is way inefficient. However, every device has to understand the jumbo packet on your LAN.
Are all your machines plugged into the switch and then one cable to the router?
How is the speed when you copy machine to machine?
Also from what I hear 9K is not better than 4K packets it depends on your hardware and it's limits...like slow pci bus, hard drive, etc.
|
|
| Top |
|
|
|
tjc
|
Posted: Sat Dec 09, 2006 6:42 pm |
|
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
MTU is a Maximum after all, the peers are supposed to negotiate based on that and get all this sorted out before hauling heavy frieght. My (simplified) wiring looks like this
Code: +-------+
|Netgear|-----Linux PC1(GigE, MTU 9000)
| GS605 |-----Liunx PC2(GigE, MTU 9000)
| GBit |
| Switch|
| |-----LinkSys Firewall Router(100Mbs)--CableModem...
+-------+
If anything my DL speeds from the net are better than they were, since the router is now handling less traffic, and facing less bottlenecks due the switches big store and forward buffers. Box to box file transfer speeds are now limited by the disk throughput. 
|
|
| Top |
|
|
|
graysky
|
Posted: Sun Dec 10, 2006 6:32 am |
|
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
My setup is like this (all machines plugged into switch and switch connected to router in uplink mode):
Code: +-------+
|Netgear|-----Win32 PC1(GigE, MTU 4088)
| GS108 |-----Linux PC2(GigE, MTU 4088)
| GBit |-----Linux PC3(GigE, MTU 4088)
| Switch|
| |-----LinkSys Firewall Router(100Mbs)--CableModem...
+-------+
My GS108's serial does indeed start with 127 indicating that it supports jumbo frames up to 9k. I have no idea why it doesn't work... could it be a LINUX netcard driver issue? If the driver I'm currently using doesn't support jumbo frames, I would think that ifconfig wouldn't allow me to set the mtu over 1500, no? The cards in the linux boxes are D-Link DGE-530T's that are supposed to support jumbo frames.
Thanks all!
_________________
Retired KM user (R4 - R6.04); friend to LH users.
|
|
| Top |
|
|
|
graysky
|
Posted: Sun Dec 10, 2006 7:18 am |
|
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
Is there anything I need to do beyond Code: # ifconfig eth0 mtu 4000 to make these work with my boxes? I also restarted nfs-common and nfs-kernel-server after the mtu size change, but that didn't do anything. I can't even browse to /mnt/video on the frontend (which is where I export videos from the backend to the frontend) when I'm using mtu size of 4000 on both boxes. Again, the only thing that works is ssh.
Curiously, if I set the mtu on the backend to 1500 and the mtu on the frontend to 4000 it works just fine..? I thought all boxes needed to be using the same mtu size?
Using the sk98lin driver on both boxes and both boxes use the same NIC (dlink 530T).
Thanks again for any ideas.
_________________
Retired KM user (R4 - R6.04); friend to LH users.
|
|
| Top |
|
|
|
tjc
|
Posted: Sun Dec 10, 2006 11:15 am |
|
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
graysky wrote: Curiously, if I set the mtu on the backend to 1500 and the mtu on the frontend to 4000 it works just fine..? I thought all boxes needed to be using the same mtu size?
They're clearly negotiating down to the slowest peer. Parameter negotiation is a normal healthy part of any IP protocol session. (BTW - I seem to remember MS-Windows has a reputaion for trying to cheat on this count, try taking it out of the circuit for a bit...) That LinkSys router in both our diagrams tops out at an MTU of 1500, but still works just fine from the faster boxes on my network. The bigger MTU for GigE is just to make the transfers more efficient. I won't try to explain the communications theory behind it, partly because it's still early for Sunday, and I'd probably botch it.
|
|
| Top |
|
|
|
graysky
|
Posted: Sun Dec 10, 2006 11:17 am |
|
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
Must be my switch... I did this test on my mythbox with mtu set to 4000 and my win32 box with "jumbo frames 4088" enabled in my NIC.
From mythbox: Code: mythtv@mythtv:~$ ping winbox -s 1490
PING winbox (winbox) 1490(1518) bytes of data.
1498 bytes from winbox: icmp_seq=1 ttl=128 time=0.205 ms
1498 bytes from winbox: icmp_seq=2 ttl=128 time=0.177 ms
1498 bytes from winbox: icmp_seq=3 ttl=128 time=0.170 ms
--- winbox ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 0.170/0.184/0.205/0.015 ms
mythtv@mythtv:~$ ping winbox -s 1500
PING winbox (winbox) 1500(1528) bytes of data.
--- winbox ping statistics ---
29 packets transmitted, 0 received, 100% packet loss, time 28010ms Compare that to this experiment: Code: mythtv@mythtv:~$ ping winbox -s 2500
PING winbox (winbox) 2500(2528) bytes of data.
--- winbox ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
As you can see, if the ping size is > the standard mtu of 1500, it times out whereas ping sizes below that standard mtu size do indeed work.
I'm pissed off if this is true since I specifically get my gigalan switch (gs108) to use jumbo frames with NICs I specifically purchased to use jumbo frames.
@tjc: can you try this ping experiment on your setup using a size of say 5000 or so?
Thanks!
_________________
Retired KM user (R4 - R6.04); friend to LH users.
|
|
| Top |
|
|
|
tjc
|
Posted: Sun Dec 10, 2006 11:41 am |
|
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
Works just fine with every size I tried...
Code: root@black2:~/setup# for size in 1000 2000 4000 8000 ; do echo "Trying $size byte packets" ; ping -c 5 -s $size x2 ; done
Trying 1000 byte packets
PING x2 (192.168.1.104) 1000(1028) bytes of data.
1008 bytes from x2 (192.168.1.104): icmp_seq=1 ttl=64 time=0.091 ms
1008 bytes from x2 (192.168.1.104): icmp_seq=2 ttl=64 time=0.107 ms
1008 bytes from x2 (192.168.1.104): icmp_seq=3 ttl=64 time=0.102 ms
1008 bytes from x2 (192.168.1.104): icmp_seq=4 ttl=64 time=0.106 ms
1008 bytes from x2 (192.168.1.104): icmp_seq=5 ttl=64 time=0.106 ms
--- x2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.091/0.102/0.107/0.010 ms
Trying 2000 byte packets
PING x2 (192.168.1.104) 2000(2028) bytes of data.
2008 bytes from x2 (192.168.1.104): icmp_seq=1 ttl=64 time=0.114 ms
2008 bytes from x2 (192.168.1.104): icmp_seq=2 ttl=64 time=0.148 ms
2008 bytes from x2 (192.168.1.104): icmp_seq=3 ttl=64 time=0.146 ms
2008 bytes from x2 (192.168.1.104): icmp_seq=4 ttl=64 time=0.149 ms
2008 bytes from x2 (192.168.1.104): icmp_seq=5 ttl=64 time=0.148 ms
--- x2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.114/0.141/0.149/0.013 ms
Trying 4000 byte packets
PING x2 (192.168.1.104) 4000(4028) bytes of data.
4008 bytes from x2 (192.168.1.104): icmp_seq=1 ttl=64 time=0.200 ms
4008 bytes from x2 (192.168.1.104): icmp_seq=2 ttl=64 time=0.226 ms
4008 bytes from x2 (192.168.1.104): icmp_seq=3 ttl=64 time=0.222 ms
4008 bytes from x2 (192.168.1.104): icmp_seq=4 ttl=64 time=0.222 ms
4008 bytes from x2 (192.168.1.104): icmp_seq=5 ttl=64 time=0.220 ms
--- x2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.200/0.218/0.226/0.009 ms
Trying 8000 byte packets
PING x2 (192.168.1.104) 8000(8028) bytes of data.
8008 bytes from x2 (192.168.1.104): icmp_seq=1 ttl=64 time=0.347 ms
8008 bytes from x2 (192.168.1.104): icmp_seq=2 ttl=64 time=0.381 ms
8008 bytes from x2 (192.168.1.104): icmp_seq=3 ttl=64 time=0.376 ms
8008 bytes from x2 (192.168.1.104): icmp_seq=4 ttl=64 time=0.369 ms
8008 bytes from x2 (192.168.1.104): icmp_seq=5 ttl=64 time=0.378 ms
--- x2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.347/0.370/0.381/0.017 ms
BTW - The router refuses to talk above 1500 as expected. Code: root@black2:~/setup# for size in 1000 2000 4000 8000 9000 ; do echo "Trying $size byte packets" ; ping -a -c 5 -s $size router ; done
Trying 1000 byte packets
PING router (192.168.1.1) 1000(1028) bytes of data.
1008 bytes from router (192.168.1.1): icmp_seq=1 ttl=150 time=1.83 ms
1008 bytes from router (192.168.1.1): icmp_seq=2 ttl=150 time=0.798 ms
1008 bytes from router (192.168.1.1): icmp_seq=3 ttl=150 time=0.796 ms
1008 bytes from router (192.168.1.1): icmp_seq=4 ttl=150 time=0.776 ms
1008 bytes from router (192.168.1.1): icmp_seq=5 ttl=150 time=0.775 ms
--- router ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 0.775/0.995/1.831/0.418 ms
Trying 2000 byte packets
PING router (192.168.1.1) 2000(2028) bytes of data.
--- router ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms
Trying 4000 byte packets
PING router (192.168.1.1) 4000(4028) bytes of data.
--- router ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms
Trying 8000 byte packets
PING router (192.168.1.1) 8000(8028) bytes of data.
--- router ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms
Trying 9000 byte packets
PING router (192.168.1.1) 9000(9028) bytes of data.
--- router ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms
|
|
| Top |
|
|
|
RacerX
|
Posted: Sun Dec 10, 2006 1:10 pm |
|
|
Joined: Sun Sep 05, 2004 7:06 pm
Posts: 690
|
|
Let's try an clear up a few things since this is a messy issue.
First, the GS108 Version 2 switch supports Jumbo Frames in it's current iteration. Since the GS108 is a plain ol' unmanaged switch, there's nothing you need (or can) do to it to use jumbo frames and in this case that's a good thing.
Second, in order to use jumbo frames all the devices on the LAN must be jumbo frames aware. Otherwise you get into a grey area with packet mismatch that you do not want to be in.
Third, the fact the backend is not working correctly with the jumbo frame is a sign that something is not right there. So what is different about the box that makes it evil? There are a couple of things to check. You pointed out the driver but how about the cable. Can you describe that hardware difference between two boxes?
The best way to test is to isolate the problem and then try and solve it. Try only cabling the front end and the backend to the switch and see if by narrwowing the field you can isolate what is going wrong...
Last edited by RacerX on Sun Dec 10, 2006 1:15 pm, edited 1 time in total.
|
|
| Top |
|
|
|
graysky
|
Posted: Sun Dec 10, 2006 1:13 pm |
|
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
tjc, thanks for the info!
I just made a crossover cable and strung the win32 box to the mythtv box.
Jumbo frames work just fine so it *has* to be my switch. I'm gonna call netgear tomorrow and figure out what's up. The GS108 is advertised to support jumbo frames (9k) if the serial number starts with 127 which mine does...
I have some older hardware (mythtv is running on a 1900+ athlon nforce2 based board and my win box is a 3200+ nforce2 based board) which may explain the giant boost of larger frame size. Here are the results of my tests moving a large file and several smaller (~150 meg or so each) files from the win to myth and from myth to win. I've concluded that my network would HUGELY benefit from a 4k MTU size. Here are the data:
Test 1/Crossover Cable (large file, 1,048,522 kb) via Samba
Code: mtu=1500 time (sec) Kb/sec
myth to win 48 21,844
win to myth 81 12,945
mtu=4000
myth to win 44 23,830
win to myth 41 25,574
mtu=9000
myth to win 49 21,398
win to myth 41 25,574
4k vs. standard % Change
myth to win 9%
win to myth 98%
9k vs. standard
myth to win -2%
win to myth 98% Test 2/Crossover Cable (several small files, 1,283,439 kb total) via SambaCode: mtu=1500 time (sec) Kb/sec
myth to win 59 21,753
win to myth 94 13,654
mtu=4000
myth to win 51 25,165
win to myth 46 27,901
mtu=9000
myth to win 57 22,516
win to myth 49 26,193
4k vs. standard % Change
myth to win 16%
win to myth 104%
9k vs. standard
myth to win 4%
win to myth 92%
-EDIT- Forgot to mention these were all xfered through Samba
What do you all think about that?
_________________
Retired KM user (R4 - R6.04); friend to LH users.
Last edited by graysky on Sun Dec 10, 2006 2:39 pm, edited 1 time in total.
|
|
| Top |
|
|
|
tjc
|
Posted: Sun Dec 10, 2006 1:45 pm |
|
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
|
Yeah, it makes a difference. File transfers between my two primary machines are limited by how fast they can read and write data to the disks. Large copies from machine to machine are actually faster than a local copy. As far as I can tell the limit is the 33Mhz PCI bus speed on the PATA drives. SATA might go faster....
|
|
| Top |
|
|
|
RacerX
|
Posted: Sun Dec 10, 2006 1:59 pm |
|
|
Joined: Sun Sep 05, 2004 7:06 pm
Posts: 690
|
The speed improvement is great 
I guess that the hardware makes all the difference
|
|
| Top |
|
|
|
graysky
|
Posted: Sun Dec 10, 2006 2:25 pm |
|
|
Joined: Wed Dec 10, 2003 8:31 pm
Posts: 1996
Location:
/dev/null
|
|
We'll see... I'm 1/2 tempted to buy a new GS108 from the store to test it. One thing I will say about netgear is they have a great warranty on their "blue box" stuff: 5 years on the unit and 2 years on the power supply (its under 1 year old).
_________________
Retired KM user (R4 - R6.04); friend to LH users.
|
|
| Top |
|
|
View unanswered posts
View active topics
Off Topic 
Print view
Previous topic Next topic 
LinHES Home
Board index
FAQ
Search
Login 
Register