Unfortunately not possible by comparing with SD. This is what I want to avoid as I do not know if the PI or the USB connection is the problem.
It is a RPI 2. Running htop (do not use sudo with it. You do not need it), I see that my CPU is quite buy doing things. Much of it comes from Octoprint.
This is also the reason, why I was so focused on tracking down the real issue: In the right column of the header up there, a so called load average is printed. This is the number of currently pending processes. It should be smaller than the number of CPUs otherwise some process will for sure be stalled. This rises clearly above 1 (single core RPI) during printing.
I will try another cable, soon. At the moment the printer is not running (no needed parts ready to print).
I have munin runnin in the network, should not be too complicated to add one more machine . I hope 5min resolution will be sufficient? Otherwise I will have to look into sysstat and nmon.
As I understand you want to check the bottleneck.
I don't quite understand the USB problem, because it is capable of sending (USB 2.0) around 20 MB/s. So not the transmission is the problem. Assuming it's 2.0 not 1.0.
you can check - as previously said "htop" or "top", you can also monitoring the serial port, for example:
You can "nice" the OctoPrint all processes a little so they would get more stable CPU constant access. I would also checked how much data is transferred to/from a sdcard where the operating system is. I would guess that can be a problem because those cards aren't too fast and when some data waits to get access to "hard drive" it can also block the USB sending. It would be command "iotop" as I remember correctly.
At the moment the printer is not running (no needed parts ready to print).
Not needed, Just prepare any printing in the air, for example 1 cm over the bed with extruder command cut off. It would send normal printing, not needed heating, not filament use and you can test it for hours.
Honestly, investing in the Raspberry Pi 3B upgrade is like $35 and is the first thing I would have done.
If I were considering leaving the pure-Raspberry space and go with a competitor, I think I would choose something with USB 3.0 support in addition to at least doubling the 1GB RAM ceiling that the Raspi 3B has. Maybe this beast with a wi-fi dongle.
I have just found usbtop, I guess it can be very helpful
Bus ID 1 (USB bus number 1) To device From device
Device ID 1 : 0.00 kb/s 0.00 kb/s
Device ID 2 : 0.00 kb/s 0.00 kb/s
Bus ID 2 (USB bus number 2) To device From device
Device ID 1 : 0.00 kb/s 0.00 kb/s
Device ID 4 : 141.73 kb/s 13777.68 kb/s
Device ID 5 : 9.98 kb/s 11.24 kb/s
Device ID 6 : 0.00 kb/s 0.00 kb/s
Device ID 7 : 0.00 kb/s 0.00 kb/s
Device ID 8 : 141.71 kb/s 15257.26 kb/s
I doubt if you will be getting 20MB/s out of a USB connection to most printers. A good number of printers that have a 32bit processor will be using the LCP176x device. These typically only support USB 2.0 Full speed mode (at least in the way they are used on printer control boards) which gives you 12MBits/s so probably around 1.5MBytes/s at best (and in reality less than that). Many of the other 32bit processors also only support the same mode. But this is still pretty fast for transferring gcode. What is probably more of an issue (as explained in the USB thread), is the protocol used over this connection which basically uses a send and wait system (send a command wait for the ok, send the next command), which can reduce the actual throughput considerably.
I'm not aware of any control boards that support USB 3.0, though I'd be happy to be proved wrong.
Yeah, sorry, I think I live in an ideal world where USB 2.0 is always High Speed.
I've installed the usbtop and printed a small detail.
The max speed to my Anet A6 I've noticed was 11 kb/s
when my camera is around 15260 kb/s
It is sending commands and there is even a 8 seconds gap (when doing skirt).
At first layer it was 1,12 kb/s quite constant, at speed 20 cm/s
Rest of printing (40-60 cm/s) around 0,6-3 kb/s and still gaps (up to 2 sec).
What is curious - speed to and from device is very close, 1,60 / 1,30 kb/s like almost every command has it's response.
Edit: by gap I mean 0,00 kb/s
Edit2: CPU is up to 15%, memory 8%
Edit3: Still - Full Speed is up to 12288kb/s, simple printing 10 kb/s. 100 times more is still 1/12 capable bandwidth (or 1/6 counting both ways, I cannot remember is 12Mb/s for one direction or both). I think it should be no problem with a USB connection.
I never had gaps so long, but please can you confirm that you print the first layer with 200mm/s and the other layers with 400 - 600mm/s ? is it centimeters what you wanted to say or milimeters ?
I noticed I have some problems when trying to increase the speed, on my DIY printer I usually print the inlay and inner walls with 80 - 100mm/s, the outer wall with 50mm/s, but to have a smooth "gap free" / stuttering free printing process I had to lower the MAXIMUM RESOLUTION in Cura, from 0.01mm to 0.1mm, after this change the printing process is running smooth - but a new problem shows up as the big radius lines are made by some 5mm long straight line, and this is where I don't understand what Maximum Resolution means, because 0.1mm is a small number, if the minimum distance between 2 gcode lines in term of X / Y coordinates will be 0.1mm (what I would expect when setting the resolution to 0.1mm) I don't know why I have some straight line segments so long, about 5mm long each
I want also to start a discussion also on Cura forum, to better understand what 0.1mm maximum resolution means for Cura developers.
I also try to find out if getting an MKS Base 1.3 32bit controller will help in terms of computation power, when trying to print fast (over 100mm/s) and with a high resolution set in slicer (0.01mm is high for me) I think not the USB link is the problem, anyway I'm not sure it's USB but Serial over USB, and the limits should be because of Serial connection on the controller side, not on the Raspberry Pi
Will a 32bit controller receive more information over the usb compared to an 8bit controller (when printing fast with 100mm/s - 150mm/s)?
PS. I haven't cleaned the prints, not even the BRIM completely.
At such low speed there shouldn't be any problem , even with the resolution set to 0.01mm. What I try to achieve is to print faster, and so far my only problem is related to this stuttering issue when printing fast and in high resolution (lower than 0.05mm).
Anyone knows if the 32bit MKS Base 1.3 board will solve this issue?
Regarding the photo above, I forgot to mention that all prints (1 - 2 - 3 - 4 - 5 - 6) ware made using print speed between 50mm/s - 60mm/s for the outer wall, and from 80mm/s - 120mm/s for the internal walls, the main difference between them was the change of resolution, as you guys can see the 3rd one is very nice on the exterior because I tried to print first the external wall, and the internal walls after, that is a 0.01mm resolution print, the exterior is perfectly smooth with no visible straight lines, to form the big radius, but on the internal walls the print is as bad as #5 .
For the first two prints #1 & #2 I used MAXIMUM RESOLUTION of 0.1mm in Cura, so there is no stuttering happening but you can clearly see the large straight segments that form the bog radius
I am going to go out on a limb and guess your machine is not mechanically capable of .0x resolution. The nozzle is probably dragging on the previous layer. If you can print things at .2 and they print fine then your issue is you are trying to make your machine do something it can not physically do or is not properly calibrated to do if the manufacture "Claims " it can.
The problem is not mechanical, and I'm not hoping to print at such high resolution ( 0.0x mm ), but what is not yet clear to me, is why when setting Cura Maximum Resolution to 0.1mm (this is still a high enough resolution to me) I get ~5mm straight line segments , one after another to form a big circle, with 0.1mm resolution set in Cura I have almost no stuttering issue , but when I increase the resolution in Cura to 0.05mm or 0.01mm the stuttering issue is ruining the prints, on the curved sections only, the long straight lines are all ok.
Also something I don't know yet, will a 32bit board like MKS Base v1.3 solve those issues regarding the number of gcode lines sent by OctoPrint via USB/serial ? As I think this is the issue, the 8bit board receives to many commands in a short period of time, and can't handle processing those lines (converting them to pulses needed for all motors)
Here are some more test to show that the actual stuttering problem comes from overloading either the serial communication or Marlin firmware on a 8 bit microcontroller, and not from the resolution of the print or the speed of printing alone, those are some factors, but in the last part of the video you can see I can print well simple models with 150mm/s without any stuttering issue.
It's important to check the communication blue leds also, when resolution is high and there are many small segments, the leds are almost continuously light up. When there are some long simple segments, but at high speed, the leds bearly light up, and no stuttering issue is shown.
. I hope 5min resolution will be sufficient? Otherwise I will have to look into 
