› ›

Repetier server often unavailable after print starts

ramRSnetramRSnet
in Questions & Answers
Hello,

I can work for hours with Repetier Server without any problems. But most of the time when I start a print job Repetier Server is no longer accessible. The printer nevertheless continues to work

When I can still log in via ssh, all parameters like CPU, RAM etc. are at most under 20%.
The parameters in the web interface (undervoltage, CPU throttled, CPU temperature, cpu load, free ram) are also ok.

The Reptier server is connected via Wi-Fi to my Fritzbox mesh. There the client is listed as offline when it has no connection anymore. All other devices with Wi-Fi have never had a problem with the Fritzbox mesh. When no print job is running everything works well.

The same behavior also occurs with Octoprint, which is accessible again after a short time.

Does anyone have any idea how I can narrow down the error further.

Best regards
Marten

System Information:
Repetier Server 1.0.3
Raspberry Pi 4 Modell B; 4 GB, ARM-Cortex-A72 4 x, 1,50 GHz, 4 GB RAM










Comments

  • RepetierRepetier
    Which image are you using? We and others have encountered connection lost with fritzbox over wifi. I still do not know this happens form time to time (have no direct connection to starting prints detected so far). In the case I could reproduce I needed to restart the linux wifi driver. The new images now have a monitor that tries to detect the problem and reloads the linux drivers. So when it happens I not see a disconnect and after some seconds I get my box now back (while in past I needed to reboot to get wifi working).

    My guess is that a special feature of the fritzbox is causing this problem, but no idea which. Maybe channel switches if you autodetect best wifi channel. So when you are on image V24 and is the same problem it should repair it self after a while. Older images where you just updated server version will not recover until reboot or if you have ethernet connection.

    What I did not understand is you said you could connect with ssh while box showed offline? But when you can connect via ssh the web gui should also work. Or was this with wired network (ssh I mean) when it was down.
  • ramRSnetramRSnet
    Where can I find the image version?

    I have roughly three scenarios when a print job is running:
    1. everything works fine and I can access the web frontend as well as via ssh.

    2. the webfrontend is not accessible but ssh works. This is always accompanied by the fact that the tab in Firefox/Chrome requires a lot of CPU on my macbook.

    3. the webfrontend and ssh do not work. In the Fritzbox web interface I see that the Raspberry Pi is offline.
    Sometimes the webfrontend or via ssh is accessible again after a certain time, sometimes not for the whole printout.

    The 3. case occurs most often. But when no print job is running I can use the webfronted or via ssh for hours !?!

    I will set the channel on the Fritzbox to fixed instead of automatic and see if the error then also happens. I use a Fritzbox and a Fritz Repeater in a mesh. Maybe that is the problem? But all other devices (smartphones, tablets, etc.) never have problems with it.






  • RepetierRepetier
    The latest image can be found here:
    https://www.repetier-server.com/download-images/

    So guess you have an old one and this should fix case 3 after a short while (maybe a minute to detect).

    2. Normally load is not that high. Do you have a webcam with high resolution and FPS? This can with not ideal wifi connection block most of the bandwidth and make the app get slow and increase cpu usage (mjpg is not ideal in terms of band width and needs constant decomposition of jpgs). I often see users wanting full hd 30FPS and wonder that they get problems when accessing via wifi. But that requires around 12MBit and bad wifi can be lower.
  • ramRSnetramRSnet
    I downloaded and installed the image the week before last. Is there nowhere to read the version of the image in the web frontend or with ssh?

    I use this webcam (AUKEY Webcam 1080p Full HD) with 1920x1080 and a frame rate of 15.
    I have now reduced the settings to 640x480 at 15 FPS and I am monitoring it. This would also explain why there are problems only while printing. With a motion image, more image information must be transferred than with a static image of the print bed.

    But the Raspberry Pi is connected to the Fritzbox Repeater with 5 MHz (433 Mbit/s up, 390 MBit/s down) and good signal strength. The Repeater itself is connected to the Fritzbox with 526 MBit/s down and 585 MBit/s up also with goog signal strength. With this, the 12MBit should not be a problem, right?

    I will monitor the network traffic while printing







  • RepetierRepetier
    No you can't see image version, but when it is only 2 weeks old it already contains the reload hack. Restarts are written to /tmp/wifi-restarts.log so check that file if you get any there. 

    Regarding speed login with ssh and run "iwconfig" - it shows the bit rate you really have. 433mb/s would be more then enough also for full hd. Then only reason for high cpu load might be the video - but it would always be the same load when you see videos so it is either always 100% or not e.g. in webcam view.
  • ramRSnetramRSnet
    I have seen the behavior again while printing:
    1. since the webcam is set to 800x600, in Firefox the energy consumption has decreased, but it is still the highest.
    Netflix, YouTube etc. need about 5% when playing video and Reptier-Server needs 30%.

    2. via web interface and ssh the Repetier-Server was unreachable again, but after a few minutes it came back.
    There is no wifi-restarts.log in the folder /tmp/.

    3. the data rate according to Fritz Repeater the Pi was connected with is 390 MBit/s down and 43 MBit/s up. Why the up-rate is so bad I will investigate further.

  • RepetierRepetier
    1. Normal. mjpg is not decoded in graphic hardware I think, so it gives more cpu load.
    2. Only happens if the driver is crashed, so no crashes. Just dropped connection until it was back. If you have a touch screen connected try setting AP to never connect. This will prevent the server from switching to AP when it thinks connection is lost.
    3. Please also ask pi with iwconfig what it thinks about data rate.
  • ramRSnetramRSnet
    I have no touch screen.

    I have logged in via ssh on the pi and 'watch -n1 iwconfig' monitored the Wi-Fi connection while printing.

    Below is the iwconfig output at the point where the webfronted is no longer accessible and I cannot connect again via ssh.  The existing ssh connection is still active and usable.

    Why the behavior is like this I don't understand. The problem also occurs when the Fritzbox repeater is plugged closer to the printer and the 'Link Quality' and 'Signal level' is better

    iwconfig output:
    Every 1.0s: iwconfig                                                                                          RepetierServer: Fri Feb  5 10:34:27 2021

    eth0      no wireless extensions.

    lo        no wireless extensions.

    wlan0     IEEE 802.11  ESSID:"NOWAY9"
              Mode:Managed  Frequency:5.54 GHz  Access Point: F0:B0:14:F8:90:B7
              Bit Rate=292.5 Mb/s   Tx-Power=31 dBm
              Retry short limit:7   RTS thr:off   Fragment thr:off
              Power Management:off
              Link Quality=49/70  Signal level=-61 dBm
              Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
              Tx excessive retries:1  Invalid misc:0   Missed beacon:0



  • RepetierRepetier
    Signal and data rate look good with 292Mb/s.

    That you can not connect to ssh might explain why server also gets problems. Strange fact is that you say the existing ssh connection is not broken. Sure about that? When you send no commands it can seem to be connected until quite a while. So only if you see content changing and can send commands it is still alive. In such a case I'd stop the watch and run some debug commands:
    free
    # H in ps shows all treads
    ps auxH
    route -n
    ifconfig
    top (after copying previous output).
    Just to see if we run into memory problems, many programs are started or what else might be going on.

    Print continues all the time right?
  • ramRSnetramRSnet
    I'm sure. Linux is part of my job. I created a video where you can see the problem. Where can I upload a 45MB video not for public?

    I tried to execute your commands, but the connection problems were too short at the current print.
    Yes the print continues all the time.

  • RepetierRepetier
    You can use dropbox or similar and send me pm with link.
  • ramRSnetramRSnet
    I have sent you a pm with the link to the video

  • RepetierRepetier
    Have seen the video. Really strange thing and no server related issue I'd say. The question is why you can not connect any more also linux has the ip assigned and is connected. Looks like a routing problem. Could it be that the pi switches between fritzbox and repeater and new connections miss the handover to the new route over repeater?
    To rule out that ssh is only not accepting new connection did you ping form mac to pi to see if route is working? I guess that is the most low level test.

    Lats thing - is it normal that fritzbox says device is unconnected when it is handled my repeater? It is same mesh and in the Orbi mesh I use I see all connected devices even the one on a sattelite.
  • ramRSnetramRSnet
    Just for fun, I turned off the 2.4 GHz Wifi on the Fritzbox and Fritz Repeater, so everything has to run on 5 GHz.
    Since then there are no more problems with the repetier server.

    It seems that the raspberry pi has problems with the automatic switch between 5 and 2.4 GHz.

    It is strange that all other devices (tablets, smartphones, ipads, macbooks) never had any issues with this.

  • RepetierRepetier
    Good information in case others suffer same problem.
Sign In or Register to comment.