Did a shoddy job converting Duet wifi to Ethernet, slow upload



  • So one of the pads was torn off, not sure if it was actually needed for the ethernet module because I can't tell where the trace is supposed to go.

    So my question is, would having this pad damaged even sever the connection to the pin that the ethernet module is soldered to?

    I was able to find schematics and the pin is still connecting to r102 meaning the missing pad does not matter and there is connectivity.

    Any idea what else could be causing this slow upload speeds of only 200-300KB/s? I can connect other devices on the same cable with much faster transfers.

    I tried formatting my SD card and it didn't help.

    (not my pictures, but arrow is showing damaged pad) This pad is not the cause of the problem after all. There is connectivity downstream. Any other ideas?
    alt text
    alt text


  • administrators

    On the Ethernet module that pin is connected to ground. The processor reads it through the URXD1 pin to test whether the Ethernet module is present.

    With firmware 2.02 and later you can run a test of the SD card speed by using M122 P105 (the P105 is from memory, I may have got it wrong) P104.



  • Did some more playing around.

    Transferring from Wifi to Duet on Ethernet still 200-300KB/s, Usually starts on the high side then drops to about 200KB/s as it settles.

    However transferring from a Ethernet connected computer to Duet on Ethernet I get about 350KB/s thought it starts off at around 800KB/s and slowly drops.

    On the other hand Ethernet compute to Wifi Computer or vice versa much faster (MB/s).

    I also tried taking the sd card and plugged it into a computer and it's getting speeds in the high MB/s it doesn't seem to be the bottle neck.

    Here is a M122 output:

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later
    Board ID: 08DDM-9FAM2-LW4S4-6J9D8-3S46N-T3TRW
    Used output buffers: 1 of 20 (17 max)
    === RTOS ===
    Static ram: 25524
    Dynamic ram: 98688 of which 0 recycled
    Exception stack ram used: 464
    Never used ram: 6396
    Tasks: NETWORK(ready,544) HEAT(blocked,1232) MAIN(running,1692) IDLE(ready,200)
    Owned mutexes:
    === Platform ===
    Last reset 14:07:33 ago, cause: software
    Last software reset at 2019-03-08 21:50, reason: User, spinning module GCodes, available RAM 6444 bytes (slot 1)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 8
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 42.0, current 42.8, max 43.1
    Supply voltage: min 24.1, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
    Driver 0: standstill, SG min/max not available
    Driver 1: standstill, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Date/time: 2019-03-09 11:58:26
    Cache data hit count 4294967295
    Slowest loop: 1.98ms; fastest: 0.08ms
    I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
    === Move ===
    Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
    Scheduled moves: 0, completed moves: 0
    Bed compensation in use: mesh
    Bed probe heights: 0.179 0.049 0.139 0.337 0.045
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.2
    Heater 1 is on, I-accum = 0.4
    === GCodes ===
    Segments left: 0
    Stack records: 3 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is idle in state(s) 0
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 5.64ms; fastest: 0.03ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 2 of 8
    Interface state 5, link 100Mbps full duplex
    === Filament sensors ===
    Extruder 0 sensor: position 0.00, ok, framing errors 0, parity errors 0, measured minimum 0%, average 0%, maximum 0% over 7308.5mm
    

  • administrators

    @norbs12 said in Did a shoddy job converting Duet wifi to Ethernet, slow upload:

    I also tried taking the sd card and plugged it into a computer and it's getting speeds in the high MB/s it doesn't seem to be the bottle neck.

    That's irrelevant, because the PC caches data when writing to SD card, so when it has apparently finished, it may not have in reality. Run M122 P104 to run the SD write speed test. Also run M39 to check the cluster size.




  • administrators

    Your SD cluster size is too small. Reformat it to 64kb clusters.



  • Thank you.



  • Not much of an improvement. The write speeds test showing 2.65MB/s now and 64kb cluster size.

    Actual transfers over network don't seem to have improved.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.