Large Ethernet MTU support?
-
Would it be possible for the Duet2 Ethernet to ask the DHCP server for the network's MTU and then use it?
It would potentially allow for faster file transfers, and in general would be nice for the Duet2 to at least recognize that the network does high MTU e.g. just potentially receive the packets without any side-effects.
-
Going from 1500 to 2000-ish probably won't make much of a difference, and wifi is limted to some 2000 bytes, add to it the cpu only has 128k ram using 9000 for something the device spends a fraction of its time doing i'd be surprised to see support for non-standard mtu. Then again, weirder things are supported so you never know.
-
@bearer I guess the opposite applies too, if DHCP says the MTU is 1486 then it would be nice if the Duets would follow that?
-
it would be considered a bug if the duet doesn't accept the minimum mtu of around 500 or so methinks, but I haven't looked at the implementation.
must admit i'm still not seeing the use case, jumbo frames outside of a san doesn't make much sense, and reducing the mtu is normally only needed on links requiring some sort of encapsulation, in which case the end points will deal with fragmentation. also reducing the mtu if the goal was to increase throughput seems a bit counter intuitive?
-
The network is far from the limiting factor for gcode upload speed. It's a matter of limited ram to handle the incoming data. Using large cluster size on the SD card helps somewhat to reduce overhead, but there's only so much you can do.
This is also part of the reason for the Duet 3 moving to support an SBC, since all the PC like functionality can be handled far better by something PC like than a motion controller could.
-
@bearer said in Large Ethernet MTU support?:
also reducing the mtu if the goal was to increase throughput seems a bit counter intuitive?
I was just listing an another case where DHCP advertised MTU would be reasonable to adhere to.
-
Sure, it would be preferable to not exceed the mtu, but its not exactly compulsory to maximize it. If it does exceed the mtu i'd flag it as a bug but I wouldn't expect mtu changes to make the top of the to-do list before there is a wider use case for it.
-
There isn't enough free RAM to make good use of higher MTU, except on Duet 3. If we did have enough free RAM then it would probably be more beneficial to use it to increase the size of the SD card write buffer.
-
The single most valuable resource in all of Duet land is the developers time.
The hours that could be spent changing MTU support this far down the road, with thousands, tens of thousands?, of Duet cards out there working fine on almost as many different networks, with no articulable benefit... well, you can see where I'm headed. Absolutely not worth the developer time.
Especially when, as pointed out above, the network stack is moving away from the on-motion-board firmware.
-
Thanks for the nice explanation.
-
By way of further explanation: SD cards are optimised for doing very large block writes. A digital camera captures several hundred Mbytes of data and needs to write it to the SD card rapidly in order to be able to take another shot. So modern SD cards have large RAM buffers to accept the data, then after it has all been received they get on with writing it to flash memory and moving blocks of data around to implement wear levelling. Unfortunately we only have 128Kb RAM total available on the Duet 2 series, so we have to do much smaller block writes. You can use the M122 P104 function (https://duet3d.dozuki.com/Wiki/Gcode#Section_M122_Diagnose) to measure the SD card write speed achieved by the Duet.