Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JoeSchmuck]

I can't imagine this not being discussed before but a quick search didn't pull up anything relevent on my question.

The MTU numbers are listed in whole thousands 3000, 4000, 5000, 6000, 7000, 8000, 9000, not 3072, 4096, 5120, 6144, 7168, 8192, 9216 which would be the standardized values.

My question is: in firmware 1.03, what are the actual values of the MTU?

Thanks for the info,
Joe

[TheWitness]

Joe,

Use Wireshark and see for yourself.  Let me know what you find.  The MTU is typically negotiated between you and your router (dhcp?), and unless you are going through a VPN, defaults to approximately 1518.  Now, Window and Packet sizes are something completely different.  I'm not sure I fully understand this.  However, I'm going to read the following:

http://en.wikipedia.org/wiki/Jumbo_frame

TheWitness

[JoeSchmuck]

Never used Wireshark.  Guess I can look into that.  So it should be able to tell me the actual MTU/Packet sizes?

[TheWitness]

Yup.  It's the "bomb".

TheWitness

[gunrunnerjohn]

Wireshark is very handy when you're trying to find out exactly what is going on over the network, it's in my standard toolbox.

[JoeSchmuck]

Just checked it out and guess I need to read the instructions.  I could swear that if I transfer a file that all the packets are the size of 6K, no matter what my jumbo frames are set to on my computers network adapter or the NAS.  I will play with it some more later and see if I'm just reading something wrong, I'm sure I am.

[TheWitness]

So, the way jumbo frame works is like this:

1) Establish a large window size with the router and upstream device.
2) Send X frames to the device that equals the jumbo frame size
3) Wait to Receive 1 ack to say the whole thing checksummed correctly.
4) If a packet checksum is not valid, resend only that frame
5) Continue to receive frames in this manner, until the file is complete

You will see lot's of smbd stuff in the middle as well.  Mostly on file state, which slows things down a lot.  Under a normal ping pong type transfer, the DNS321 will only send a few frames, or even 1 frame, before it expects an ack.  This is why we call it ping pong.  If you have high latency, this totally screws your transfer rate.  If you assume a RTL (Round Trip Latency) of 300 MS, you can only get 3 frames per second, or about 4k of data.  If you are paying for GigE international links, that would result in a frosting like you would never know.

So, what Jumbo Frame does, or is at least supposed to do is reduce the number of acks required to complete a transaction thus allowing the throughput to be higher.  The TCP window also controls that behavior as well.  It's all to complicated for me...

TheWitness

[JoeSchmuck]

I fully understand the handshaking going on, it's been around for a long long time.  I recall using 110 Baud acustical modems and if you didn't understand which handshaking protocol you needed, you would get some odd characters scroll across your printout (not a video screen).  So learning handshaking protocols was mandatory.  It's actually easy stuff.  Jumbo frams is easy too.  I just haven't needed to look at handshaking much in the past 30 years except for specialized government system, which we will not go into.

So, I need to play around with wireshark a bit, maybe tomorrow.  Make sure I'm even looking at the correct data.  I started capturing the ethernet port, transferred a file, stopped the capture, looked at the data.  I'll get into it some more when I have some free time.

Thanks for telling me about this tool.

-Joe