Hi!
Where is the reason for slowly working network? All network futures on smoothieboard are so slow that the network is practicaly useless. Between printing the printer stops more time. I also tried plan9 network filesystem. For transfering 25Mb file it took more than one hour. I think that this are not normal conditions. What is the solution?
Imported from wikidot
Hi
I also find this issue ,Where is the reason for slowly working network? What is the solution?
Hi !
The limiting factor here is the SD card. Access to the SD card from Smoothie is slow and can not be made better.
If you want fast printing via network, try streaming G-code using Pronterface, that’ll be much faster than going to the SD card first.
Cheers.
Hi!
Not only sd access is slow.
I suspect the limitations of uip has something to do with it.
Googling “uip delayed ack” turns up some interesting results.
Hi
I tried streaming G-code using Pronterface. It works fine via USB but when I print via network, the printer get stuck for about 0.5 sec each few lines of G-code and sometimes disconnect error occurs in Pronterface.([ERROR] Can’t write to printer (disconnected?))
Has this issue been addressed or resolved? Because I have the same problem. I also have another problem that the Smoothieboard doesn’t want to use DHCP properly, because I just figured out that it is registering some random IP address not on my local network, whereas all other DHCP-using devices in my position manage to get their IP addresses from my router. But with that issue finally solved, I find that the interface is ridiculously slow. I pressed the “X + 10” button on the webpage, counted 8 seconds, and then the printer head moved. If I click the button three times in a row, rapidly, then again I wait 8 seconds, then the printer responds with 3 quick head movements. If I continuously click short movements (“X + 1”), they appear to be processed in bursts about 6-10 seconds apart.
If the issue is the ack per packet then no and it will not be addressed as there is not enough memory to handle the usual multiple packet ack strategy used in most TCP/IP implementations. (This is a UiP issue and cannot be fixed).
If the issue is slow writes to the sdcard that is currently being worked on and apprears to have a significant increase in read and write speed.
(This is a UiP issue and cannot be fixed)
Darn. It’s unintuitive that under the right circumstances, a 100Mb ethernet line is way slower than a USB cable…
Could it be more than this, though? What I’ve seen about the UiP issue is that (1) the UiP implementation is slower due to strict memory limits, but that should not be noticeable for simple communications like sending individual commands, and (2) the serious issue with the delayed ACK is supposed to be solved by splitting packets in two parts, which results in overall (slightly) slower behavior but does not fall prey to the 500ms-per-packet timeout if an ACK is sent before the processor is ready to receive it. The packet splitting is definitely enabled in the code, so the Smoothieware implementation should not have that problem.
And none of this really matches up to my experience of up to 10 second timeouts.
I notice that up front in libs/USBDevice/USBDevice/USBHAL_LPC17.cpp there is a call to NVIC_EnableIRQ(USB_IRQn), and in libs/Kernel.cpp there is a call to NVIC_SetPriority(USB_IRQn, 5). So the USB interface appears to be interrupt-controlled. But if I do a search for ENET_IRQ in the source code, I come up with nothing other than the definition of the IRQ number. It appears that the ethernet module only processes incoming packets during on_idle(), not by interrupt. Is that intentional? I admit that I don’t really understand the code all that well. The irq routine is all commented out, and I assume that’s on purpose.
yes it is deliberate.