upload over wlan very slow
upload over wlan very slow, i.e. the transmission from the prusa slicer via prusa link is very slow, whether it is printing or not does not matter, is it so desirable that a 10 MB file takes over a minute, Lg Lino
RE: Lucky you!
I just clocked a 15.8 MByte file 4 minutes and 18 seconds to be uploaded to an idle printer using Prusa Link. That's around 4 Mbps. Uploads using PrusaSlicer 2.3.3 2.2 are clocked at 400 Kbps (10 times slower). And a test raw upload using just netcat flew at 10 Mbps.
So it seems there is a lot of room for improvement on that front and the good news is that it does not seem to need to be that slow.
Please note my printer is not so close to the wifi access point, so better results are definitely possible.
High CPU usage while uploading
I recall when I was wondering why it's so slow (upload from PrusaSlicer 2.3), I ran top on the prusalink over ssh and noticed the CPU was 100% utilized by a some prusalink process (don't recall the exact name), so it seems there might be an inefficient code causing this.
Re: The upload is limited
But that says it's The upload is limited while printing while in fact it's slow even while not printing.
Re
Because it makes no difference whether you print or not, it is generally limited. Maybe will be improved in a later version
I was wrong, I was using PrusaSlicer 2.2 on the test computer
I have got 530 Kbps when uploading a project from PrusaSlicer 2.3.3 to the Raspi Zero W.
TX vs RX
I have clocked the transfer of a file of a g-code file, 6.452.095 bytes long, being transferred to and from the Raspi using nc (netcat):
It took 4.6 seconds to be received by the Raspi and 3.2 seconds to be transmitted by the Raspi. This makes sense as writing the file to the SD is slower than reading from it. That translates to a throughput of around 11 Mbps RX and 16 Mbps TX when the printer is idle.
A few seconds for a few megabytes is something I would be ok with. Several minutes (as it happens now) .
A similar file uploaded with Prusa Link web interface only achieved 580 kbps, taking almost two minutes.
The way I see it, going from seconds to minutes is what makes the current performance difficult to accept: It will be much faster to move the SD card to the computer and back to the printer, which kind of defeat the purpose (of course if computer and printer are nearby and so is the user :-).
RE: speedtest-cli
I have tested a CLI python app for speed test with the Raspi:
$ speedtest-cli --bytes Retrieving speedtest.net configuration... Testing from Entidad Publica Empresarial Red.es (158.42.58.21)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Anna Telecom (Anna) [56.86 km]: 23.825 ms Testing download speed................................................................................ Download: 0.89 Mbyte/s Testing upload speed...................................................................................................... Upload: 1.84 Mbyte/s
Or if you prefer, another test in bps instead of bytes/sec:
speedtest-cli Retrieving speedtest.net configuration... Testing from Entidad Publica Empresarial Red.es (158.42.58.21)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Anna Telecom (Anna) [56.86 km]: 19.521 ms Testing download speed................................................................................ Download: 11.57 Mbit/s Testing upload speed...................................................................................................... Upload: 16.16 Mbit/s
Or the more visually appealing ...
With a better wifi connection
I have done another speed test with another Raspi Zero W, this time at home and using a stock Raspbian (without prusa link installed), closer to the wifi access point and this are the results:
$ .local/bin/speedtest Retrieving speedtest.net configuration... Testing from Telefonica de Espana (83.37.111.123)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by aeromax (Alicante) [127.72 km]: 32.365 ms Testing download speed................................................................................ Download: 15.37 Mbit/s Testing upload speed...................................................................................................... Upload: 20.36 Mbit/s
If I have to choose between my printer stopping for a second but having uploads in a few seconds or having to wait minutes for an upload but being sure the print never stops occasionally I would choose the former.
RE: .
Installed speedtest-cli on Prusalink image and i'm coming up with the same results.
:~ $ speedtest-cli --bytes --simple Ping: 54.585 ms Download: 1.47 Mbyte/s Upload: 2.19 Mbyte/s :~ $ speedtest-cli --simple Ping: 55.593 ms Download: 11.99 Mbit/s Upload: 13.29 Mbit/s
Wireless signal looks decent as well with the device.
:~ $ iwconfig
lo no wireless extensions.
wlan0 IEEE 802.11 ESSID:"XXXXXXXXXX"
Mode:Managed Frequency:2.417 GHz Access Point: XX:XX:XX:XX:XX:XX
Bit Rate=65 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=59/70 Signal level=-51 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:8 Invalid misc:0 Missed beacon:0
Limiting network rate
While the printer is printing, I can understand the priority is printing as well as possible. During that time, a limitation on the download speed might be in place to prevent the print buffer to be exhausted, forcing an undesired pause of the ongoing print.
But when the printer is idle, such a limitation on the download speed should not be active as there is nothing to protect but the sanity of the user. Making project download slower then serves no purpose other than causing user frustration. Not a good thing (tm).
My proposal is therefore to make the download rate limit conditional to the printer being printing and disabled otherwise.
Limiting or inefficient?
I'll reiterate the observed 100% CPU usage during upload (while NOT printing), either by web interface or prusaslicer. Checked again what process it is in htop and it's simply python3 running the prusalink package. That's unlikely to be result intentional limiting, as ultimately the point of limiting would be to prevent CPU usage by limiting the upload speed. Most likely it's some inefficient python code.