Print

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

[itz420]

I have a DGL-4500, D-Link DGE-530T Gigabit Ethernet Adapter, and cat 6 cable for my Ethernet cords. Can I use the jumbo frame setting, and what would be the correct setting.  Also, is there some setting on my router that I have to configure?

[itz420]

Can anyone know the answer to this question or is it an unknown thing

[fordem]

Jumbo frame is sort of a "non-standard" standard.

For most of us answering your question would mean downloading or otherwise researching the specification of your equipment to determine if it supports jumbo frame as well as what frame size it supports and then the most we could do is suggest a frame size as a starting point and tell you to try it and see.

It's actually quicker to just go into the device configuration/properties and fiddle.

Using Google - the DGE530T support jumbo frame, but there is some doubt as to whether or not it's supported on the DGL4500 - D-Link's website doesn't mention it, but the Realtek chipset used apparently does.

So we're still in the same spot - go fiddle with it.

[Lycan]

More then likely you're not going to see a performance increase with jumbo frames. Jumbo frames are for corporate networks that are moving extremly large packets around. In fact I'd wager that your streaming media performance and Internet browsing speeds will suffer the most.

[ECF]

The DGL-4500 supports Jumbo frames at up to 4000 bytes. 

[fordem]

More then likely you're not going to see a performance increase with jumbo frames. Jumbo frames are for corporate networks that are moving extremly large packets around. In fact I'd wager that your streaming media performance and Internet browsing speeds will suffer the most.

Corporate network or not, it IS the size of the frame that determines the size of the packet - so if you don't have jumbo frame then the packet is limited to the standard 1500 bit frame, and if you do have jumbo frame, then the size of the packet is limited by the smaller of the two frame sizes permitted on the host devices (if you set one end for 4000 and the other for 9000 - they will negotiate and settle on a 4000 bit frame).

Also corporate networks don't necessarily have large data files flowing across them - it depends on the nature of the business and it is perhaps at the corporate level that you will find application developers using SQL type databases with relatively small data transfer requirements.

[Lycan]

Correct but multimedia applications are not designed to work with jumbo frames, it forces the PC and the Swith to work harder to sort the smaller frames for streaming.
In testing I've done our routers perform better without jumbo frames.
Also when traversing NAT, the NAT now has to framgment the larger frames and sort them before leaving the WAN port.

[fordem]

Correct but multimedia applications are not designed to work with jumbo frames, it forces the PC and the Swith to work harder to sort the smaller frames for streaming.
In testing I've done our routers perform better without jumbo frames.
Also when traversing NAT, the NAT now has to framgment the larger frames and sort them before leaving the WAN port.

I won't get into a discussion on the effects of jumbo frame on multi media streaming - since media is not my thing and I have very little experience with it, I will take your word for it, but, let's look at that NAT traversal thing - jumbo frame should have NO impact whatsoever on web browsing - once you configure your router correctly.

Most routers do not have gigabit interfaces (and that includes routers like the DGL-4500 which have integrated gigabit switches - the switch uses a five port Realtek asic that is completely separate from the router) and cannot be configured for jumbo frame - if the router is configured for a standard 1500 bit frame and the host at the other end is configured for a 9000 bit jumbo frame, they will negotiate a common MSS which will be 1500 bit (or whatever MTU the router is configured for) and there will be no fragmentation issues

[Lycan]

I wasn't referring to the swtich. I was referring to the NAT CPU.
If the data leaving the client is 4k and the switch on the 4500 is 4k compatible (whitch it is) what happens when the frame is intended to leave the WAN? The NAT CPU has to fragment it.
Also, there is no jumbo frame configuration, it's simply auto detection of frame size via negotion up to 4k.

[fordem]

It's so easy to lose sight of the trees in the forest.

The switch is nothing but a conduit between the router and the network host - since you cannot configure the router for jumbo frame, when the router and the client negotiate the MSS it will be 1500 bits so that will be the size of the packet being sent by the host, and so the router will not fragment it.

Let me see if I can make this a little clearer.

Imagine if you will, that you have a router and a five port switch, two separate devices - you plug the router into port 5 on the switch and you plug the client system into port 1 on the switch.

The client system allows you to configure a jumbo frame with a size of 4000 bits, the router does not allow jumbo frame - the two devices automatically negotiate the MSS, which will be 1500 bits (because the router cannot accomodate a larger frame), so the client system will send 1500 bit frames, and the router will not fragment them.

Let us now connect the DNS-323 to the five port switch, let's plug that in to port 2 - the client system and the DNS-323 will now negotiate the MSS, which will again be 1500 bits and the two will communicate with no trouble - the user opens a browser on the client system and logs into the DNS-323 and configures that for jumbo frame (4000 bits) and now the two will negotiate an MSS with a 4000 bit limit.

Let us not forget that it is entirely possible to have devices with different frame sizes on the same LAN - if it weren't there would be no way to configure the DNS-323 for jumbo frame (either one device or the other HAS to be set for jumbo frame first)

Get the idea?

OK - now let's squash our router and our five port switch into one cabinet - presto we have a DGL-4500.

[Lycan]

Trees in the forest eh,

How about the fact that path MTU discovery almost always fails over a WAN path.

How about another tree coming up that this device will acctually drop the ICMP type 3 messages integral to path MTU discovery as a security measure.

Without the thought that path MTU, a tequnique that only works in tight, controlled networks gardens will operate in the worlds forrest of a WAN we agree perfectly.

without path MTU fragmentation begins

fragmentation = slowdown

This is becoming tedious it will be locked very soon.

To document my anwsers see the following wiki.
http://en.wikipedia.org/wiki/Maximum_transmission_unit#Path_MTU_discovery

[fordem]

Now there's a novel concept - user disagrees with moderator, moderator threatens to lock thread.

In words of as few syllables as possible.

What you keep missing is that since the router does not support jumbo frame, the client system will not send any frame larger than 1500 bits to it, even if the client system is configured for a larger frame, MSS takes care of that.

A client system configured for jumbo frame will not attempt to send jumbo frame to any host not on the local LAN because the router does not support jumbo frame - there will be no more fragmentation than would have occured if the client system had been configured for a standard frame size.

MTU path discovery plays no part in this

RFC 1191 describes "Path MTU discovery", a technique for determining the path MTU between two IP hosts. It works by setting the DF (Don't Fragment) option in the IP headers of outgoing packets. Any device along the path whose MTU is smaller than the packet will drop such packets and send back an ICMP "Destination Unreachable (Datagram Too Big)" message containing its MTU, allowing the source host to reduce its assumed path MTU appropriately. The process repeats until the MTU is small enough to traverse the entire path without fragmentation.

MTU path discovery is what determines the MTU when the path involves multiple hops between hosts - that is layer 3 technology - we are dealing with MSS at layer 2

[fordem]

Oh - I forgot - feel free to lock the thread, ban me and delete the posts.

The bottom line - at least for me - is this statement, which is what I did not agree with, is still incorrect.

Jumbo frames are for corporate networks that are moving extremly large packets around

As I said in the initial response - corporate or not the packet size is determined by the frame size - and you will find corporate LANs using standard 1500 byte frames.

[Fatman]

I think the problem was not that you disagree, it is that this is becoming an adversarial thread.

We are talking about a layer 3 environment, this discussion became whether or not fragmentation and therefore slowdown happens when browsing the web with jumbo frames on, this is a layer 3 situation.

Besides, MSS "negotiation" is a part of the TCP header, what layer is TCP in again?  It is also not negotiation just a statement of preferences by the 2 endpoints, and it does not speak a lick for anything in the middle.  Now path MTU is a layer 3 solution to infer layer 2 compatibility in the middle.

Though it appears you may be speaking to a different problem than Lycan, and no one is speaking to the original problem.  The real point is the original question was answered a long time ago.

[Lycan]

Now that we've cleared the air in regards to this, I'm going to lock the thread. This is in no way done as a affront to anyone. Only as a way to ensure that more time and effort is not wasted here.