WiFi Unreliable
-
@phaedrux Question, is it possible to view the dashboard via OctoPrint or another way? I'm trying to see if I can bridge the connection to mitigate the WiFi issue
-
@dessiverse said in WiFi Unreliable:
Is there any diagnosing things I can do to confirm if that is the case somehow?
Maybe try tracert (win) or traceroute (linux) to the Duet from other machines may give some clues. If there are repeaters involved the results may (or not
) point to some differences.
Also - is the repeater a bridge (same ip subnet on either side of the repeater) or is there a different subnet to the router? If the latter - what happens when everything is on the router side with the repeater turned off (just for luck
) ? -
@stuartofmt I tried SSHing into the duet but it wasn't letting me connect? It kept saying connection refused so I couldn't diagnose most things at its end
-
@dessiverse, here is how you can test whether it is the WiFi or the SD card writing that is slowing down the upload speed in standalone mode:
-
To test the upload speed, rename a large GCode file (or any other file) to a name ending in ".dummy", then try to upload it on the Jobs page. You will need to set the file filter to "all files" to allow you to select that file. This will upload the file without writing it to SD card.
-
To test the SD card write speed, send M122 P104.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
-
@dc42 It's not the SD Card because when using the duet in AP mode the upload speed was perfectly fine. So that loops it back to, how do I narrow down what's causing the WiFi on the duet to be slow when it isn't a problem with other devices on the network?
-
@dessiverse said in WiFi Unreliable:
I tried SSHing into the duet
I'm not aware that Duet supports SSH so that error makes sense
What I had in mind was from some other machine (like the one that you are trying to upload from) to the Duet. e.g. tracert Ip-address-of-duet.
What you want to see is a direct connection - something like this (from my win machine to my Duet (at 192.168.1.150:C:\Users\stuar>tracert 192.168.86.235 Tracing route to 192.168.86.235 over a maximum of 30 hops 1 164 ms 7 ms 9 ms 192.168.1.150 Trace complete.Thinking about this - better commands may be pathping (win) or tracepath (linux). They basically combine tracert and ping in one command. For example - my equivalent of the above is:
C:\Users\stuar>pathping 192.168.86.235 Tracing route to 192.168.1.150 over a maximum of 30 hops 0 Stuart [192.168.1.5] 1 192.168.1.150 Computing statistics for 25 seconds... Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 Stuart [192.168.1.5] 0/ 100 = 0% | 1 9ms 0/ 100 = 0% 0/ 100 = 0% 192.168.1.150 Trace complete.and throw in the results of ping for good measure.
Basically just trying to rule out any strange network routing.
-
@dc42 said in WiFi Unreliable:
M122 P104.
Result of this is
Send: M122 P104 Recv: Testing SD card write speed... Recv: SD write speed for 10.0Mbyte file was 2.66Mbytes/sec Recv: Testing SD card read speed... Recv: SD read speed for 10.0Mbyte file was 1.54Mbytes/sec -
@stuartofmt here's the results of that test:
destinybonavita@MacBook-Pro ~ % traceroute 10.0.0.201 traceroute to 10.0.0.201 (10.0.0.201), 64 hops max, 52 byte packets 1 10.0.0.201 (10.0.0.201) 8.712 ms 13.885 ms 5.475 ms destinybonavita@MacBook-Pro ~ % ping 10.0.0.201 PING 10.0.0.201 (10.0.0.201): 56 data bytes 64 bytes from 10.0.0.201: icmp_seq=0 ttl=255 time=13.169 ms 64 bytes from 10.0.0.201: icmp_seq=1 ttl=255 time=11.783 ms 64 bytes from 10.0.0.201: icmp_seq=2 ttl=255 time=34.763 ms 64 bytes from 10.0.0.201: icmp_seq=3 ttl=255 time=6.772 ms 64 bytes from 10.0.0.201: icmp_seq=4 ttl=255 time=51.055 ms 64 bytes from 10.0.0.201: icmp_seq=5 ttl=255 time=9.359 ms 64 bytes from 10.0.0.201: icmp_seq=6 ttl=255 time=12.984 ms 64 bytes from 10.0.0.201: icmp_seq=7 ttl=255 time=8.528 ms 64 bytes from 10.0.0.201: icmp_seq=8 ttl=255 time=23.638 ms Request timeout for icmp_seq 9 64 bytes from 10.0.0.201: icmp_seq=10 ttl=255 time=15.351 ms 64 bytes from 10.0.0.201: icmp_seq=11 ttl=255 time=18.995 ms Request timeout for icmp_seq 12 64 bytes from 10.0.0.201: icmp_seq=13 ttl=255 time=34.696 ms 64 bytes from 10.0.0.201: icmp_seq=14 ttl=255 time=52.520 ms 64 bytes from 10.0.0.201: icmp_seq=15 ttl=255 time=4.912 ms 64 bytes from 10.0.0.201: icmp_seq=16 ttl=255 time=21.125 ms 64 bytes from 10.0.0.201: icmp_seq=17 ttl=255 time=13.998 ms 64 bytes from 10.0.0.201: icmp_seq=18 ttl=255 time=36.809 ms ^C --- 10.0.0.201 ping statistics --- 19 packets transmitted, 17 packets received, 10.5% packet loss round-trip min/avg/max/stddev = 4.912/21.792/52.520/14.487 ms -
@dessiverse said in WiFi Unreliable:
here's the results of that test
Don't like the timeouts on a LAN ... What happens when you ping the router ? Do you see time out's occurring there ?
-
@stuartofmt nope
destinybonavita@MacBook-Pro ~ % ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=5.392 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=7.069 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=4.732 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=5.586 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=4.150 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=3.499 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=4.984 ms 64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=10.994 ms 64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=10.078 ms 64 bytes from 10.0.0.1: icmp_seq=9 ttl=64 time=1.937 ms 64 bytes from 10.0.0.1: icmp_seq=10 ttl=64 time=3.131 ms 64 bytes from 10.0.0.1: icmp_seq=11 ttl=64 time=3.873 ms 64 bytes from 10.0.0.1: icmp_seq=12 ttl=64 time=11.292 ms 64 bytes from 10.0.0.1: icmp_seq=13 ttl=64 time=5.367 ms 64 bytes from 10.0.0.1: icmp_seq=14 ttl=64 time=4.908 ms 64 bytes from 10.0.0.1: icmp_seq=15 ttl=64 time=10.782 ms 64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=4.683 ms 64 bytes from 10.0.0.1: icmp_seq=17 ttl=64 time=2.373 ms 64 bytes from 10.0.0.1: icmp_seq=18 ttl=64 time=2.985 ms 64 bytes from 10.0.0.1: icmp_seq=19 ttl=64 time=2.831 ms 64 bytes from 10.0.0.1: icmp_seq=20 ttl=64 time=4.145 ms 64 bytes from 10.0.0.1: icmp_seq=21 ttl=64 time=5.388 ms 64 bytes from 10.0.0.1: icmp_seq=22 ttl=64 time=12.284 ms 64 bytes from 10.0.0.1: icmp_seq=23 ttl=64 time=5.878 ms 64 bytes from 10.0.0.1: icmp_seq=24 ttl=64 time=9.148 ms 64 bytes from 10.0.0.1: icmp_seq=25 ttl=64 time=10.261 ms ^C --- 10.0.0.1 ping statistics --- 26 packets transmitted, 26 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.937/6.067/12.284/3.055 ms destinybonavita@MacBook-Pro ~ % -
Do you have access to any xfinity router config pages?
Can you contact the ISP for some support?
Do you have a separate router you can setup as an access point to test with? -
@phaedrux I have access to the config pages. If I contact the ISP they'll definitely say it's a problem with this device since everything else on the network runs flawlessly.
-
Is it creating a separate 2.4ghz network SSID or are they combined?
Do you see any options for band steering or whatever name they give it which tries to shunt devices to the 5ghz network? -
@phaedrux said in WiFi Unreliable:
band steering
I have the setting for this. It’s also one combined SSID for 2.4 and 5 due to the extenders.
-
I would try setting up a separate 2.4ghz SSID with the router itself, no extender, and just see if the performance is better. Try and isolate where the issue lies.
-
@dessiverse said in WiFi Unreliable:
@stuartofmt nope
Ok - so it may have something to do with the Duet itself.
The only thing I can suggest at this stage, network-wise, is to eliminate variables. Getting the Duet and the machine that you wish to download from directly connected to the router (i.e. no repeater in the picture) would be a good start.
P.S. the results you got from the M122 P104 test look almost exactly the same as on my Duet2 Wifi. Downloading a gcode file that is 25MB takes about a minute, the same if I upload it from Prusa Slicer. The .dummy test seems about 10 sec quicker for the same file.
-
@phaedrux I originally had it like that and it was the same. I changed it a few days after.
-
@stuartofmt I had this issue before I got the repeaters and when I had the networks separated. I also tried with the duet being the only one on the 2.4GHz network and had the same issue. I really think it's a problem with the duet itself.
-
@dessiverse said in WiFi Unreliable:
I really think it's a problem with the duet itself.
Yet the speeds are fine when connecting to the Duet in AP mode. It seems more an issue of the local router not playing well with the Duet.
-
@dessiverse said in WiFi Unreliable:
I really think it's a problem with the duet itself.
How about trying a file transfer using FTP? As @Phaedrux said, its strange that when configured as an AP it works well. Maybe testing as an AP and as part of the desired network and compare the results.
I'm only suggesting FTP as a way of taking the Duet Code out of the equation and gathering additional data. Again - it may tell something or nothing ...
