Linux VS Windows

[Teius92]

Salve a tutti, qualcuno ha mai verificato l'uguaglianza prestazionale di stampa sfruttando il medesimo slicer nei 2 diversi sistemi operativi? Sarei curioso di sapere se cambia qualcosa perché, ho un vecchio portatile che uso quando devo ammazzare il tempo fuori casa, e con Windows gira bene, ma un po' sforzato.

Freecad e Cura lo mettono in difficoltà e so che Linux gira in modo più leggero. 

Grazie.

[Drvo]

La velocità di lettura del gcode viene influenzata dall'hdd\ssd\sd. Ci sono comunque e ovviamente dei limiti di velocità di lettura che dipendono dalla stampante ma in generale basta un hdd per non avere alcun problema.... anzi, anche una normalissima sd. Quindi, secondo me, non ti cambia nulla.... linux di sicuro essendo più leggero può far guadagnare risorse al pc e magari ha anche meno accessi in lettura e scrittura confronto a windows.

[Maso]

La stampa non viene influenzata dal s.o. sul quale gira lo slicer, se fosse ci sarebbe una differenza tra le versioni dello slicer per i diversi s.o. ma non credo proprio questo si verifichi.

Quello che ho provato è che su Linux Mint freecad gira leggermente meglio che su Windows. Ciò che veramente fa la differenza è invece lo slicer, Cura è davvero molto lento ad aprirsi, mentre invece altri tipo ideamaker è una scheggia, e questo indifferentemente dal s.o.

[Drvo]

5 minuti fa, Maso ha scritto:

La stampa non viene influenzata dal s.o. sul quale gira lo slicer, se fosse ci sarebbe una differenza tra le versioni dello slicer per i diversi s.o. ma non credo proprio questo si verifichi.

Quello che ho provato è che su Linux Mint freecad gira leggermente meglio che su Windows. Ciò che veramente fa la differenza è invece lo slicer, Cura è davvero molto lento ad aprirsi, mentre invece altri tipo ideamaker è una scheggia, e questo indifferentemente dal s.o.

L'os può influenzare solo se, in qualche modo, crea rallentamenti a livello di lettura. Quando tu invii una stampa tramite usb con cura (esempio), la stampa 3d va a leggere il gcode man mano e se l'hdd viene rallentano troppo per qualche motivo la stampante 3d arriva persino a bloccarsi fin quando non riesce a leggere le successive istruzioni.

Ovviamente, è un esempio forzato perché comunque un os non ti rallenta a tal punto l'hdd a meno che non ci sono problemi software. Quindi, si, l'os non ti cambia nulla.... però sicuramente su una macchina vecchia linux essendo più leggero permette meno carico sulle risorse in generale e se si ha anche un hdd vecchio: avere un os che legge e scrive meno non è per nulla male per una maggiore tranquillità.

[eaman]

12 hours ago, Drvo said:

Quando tu invii una stampa tramite usb con cura (esempio), la stampa 3d va a leggere il gcode man mano e se l'hdd viene rallentano troppo per qualche motivo la stampante 3d arriva persino a bloccarsi fin quando non riesce a leggere le successive istruzioni.

Hemm no, un file da stampare in genere e' qualche MB, a volte raramente  qualcosa di enorme piuo' raggiungere ~40MB. Gli hard disk magnetici di una volta tirano 80MB/s, gli SSD che usiamo ora almeno fanno 400MB/s e alcune *cose moderne fanno 5 volte tanto. Quindi il tuo OS ci mette una frazione di secondo a leggere i dati dal supporto di storaggio, e c'e' una cache pure nel supporto di storaggio stesso oltre che nel kernel e nell'OS.

Il problema che hai e' che tipicamente il chip di emulazione seriale / USB sulle schede 8bit (tipo ATMEL) delle stampanti sono dei cessi, i CH30 funzionano pure male su windows ma non su linux. Oppure al massimo e' la scheda della stampante che non riesce a elaborare file pesanti con alte velocita' ma il sistema operativo su cui gira lo slicer non centra assolutamente niente. Il sistema operativo che gira sulla scheda della stampante puo' influire molto, es Klipper piuttosto che Marlin.

[Drvo]

2 minuti fa, eaman ha scritto:

Hemm no, un file da stampare in genere e' qualche MB, a volte raramente  qualcosa di enorme piuo' raggiungere ~40MB. Gli hard disk magnetici di una volta tirano 80MB/s, gli SSD che usiamo ora almeno fanno 400MB/s e alcune *cose moderne fanno 5 volte tanto. Quindi il tuo OS ci mette una frazione di secondo a leggere i dati dal supporto di storaggio, e c'e' una cache pure nel supporto di storaggio stesso oltre che nel kernel e nell'OS.

Il problema che hai e' che tipicamente il chip di emulazione seriale / USB sulle schede 8bit (tipo ATMEL) delle stampanti sono dei cessi, i CH30 funzionano pure male su windows ma non su linux. Oppure al massimo e' la scheda della stampante che non riesce a elaborare file pesanti con alte velocita' ma il sistema operativo su cui gira lo slicer non centra assolutamente niente. Il sistema operativo che gira sulla scheda della stampante puo' influire molto, es Klipper piuttosto che Marlin.

Prova ad avviare una stampa e a stressare l'hdd (il mio hdd raggiunge i 150mb/s). Sono dei test che ho fatto e la mia stampante si bloccava per via dell'hdd stressato da me. Ma questo stress non lo ottieni semplicemente da un OS... è ovvio, però su HDD molto vecchi dove magari la meccanica è usurata basta poco per vederli lavorare come dei dannati senza motivo.

[eaman]

6 minutes ago, Drvo said:

Prova ad avviare una stampa e a stressa l'hdd. Sono dei test che ho fatto e la mia stampante si bloccava per via dell'hdd stressato da me. Ma questo stress non lo ottieni semplicemente da un OS... è ovvio, però su HDD molto vecchi dove magari la meccanica è usurata basta poco per vederli lavorare come dei dannati senza motivo.

 

----

Questi sono 2 hd "rossi" da server di ~15anni fa che girano su atom sempre di 15anni fa: 532.16 MB/sec cached (e un gcode sta in cache) o  146.77 MB/sec in lettura, che sara' poi la meta', e' che sono in RAID mirror.

La meccanica usurata? Un hard disk funziona o non funziona... Non e' che gira a velocita' random!

chrome:~# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   1064 MB in  2.00 seconds = 532.16 MB/sec
 Timing buffered disk reads: 442 MB in  3.01 seconds = 146.77 MB/sec

chrome:~# hdparm -i /dev/sda

/dev/sda:

 Model=WDC WD20EFRX-68EUZN0, FwRev=82.00A82, SerialNo=WD-WCC4M1YNF34E
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }


chrome:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU  330   @ 1.60GHz

[Drvo]

1 minuto fa, eaman ha scritto:

chrome:~# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   1064 MB in  2.00 seconds = 532.16 MB/sec
 Timing buffered disk reads: 442 MB in  3.01 seconds = 146.77 MB/sec

chrome:~# hdparm -i /dev/sda

/dev/sda:

 Model=WDC WD20EFRX-68EUZN0, FwRev=82.00A82, SerialNo=WD-WCC4M1YNF34E
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }


chrome:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU  330   @ 1.60GHz

Questi sono 2 hd "rossi" da server di ~15anni fa che girano su atom sempre di 15anni fa: 532.16 MB/sec cached (e un gcode sta in cache) o  146.77 MB/sec in lettura, che sara' poi la meta', e' che sono in RAID mirror.

 

I miei esempi e i miei test sono stati in determinati condizioni anche perché, come per tutti i test, sono estremi. Non ottieni un blocco della stampa semplicemente avviando una stampa da un hdd di 15 anni... anche perché gli hdd sono gli stessi da ormai secoli.. devono avere dei problemi di meccanica per vederli lavorare in modo insensato (registri corrotti, disco graffiato e usurato, ecc). Quando stressi un hdd lo stressi in tutte le sue funzioni e prestazioni quindi: cache, velocità, ecc, sono tutte funzionalità prese in causa.

Comunque sia, si sta discutendo del nulla xD.... io ho solo fatto presente dei test che feci all'inizio (e ai primi avvii della mia prima stampante) per confermare e verificare il modo di lavorare l'invio del file di stampa via usb. Quindi, non sono situazioni reali che si possono presentare su pc sani o comunque su periferiche sane ma sono comunque condizioni che si possono presentare in determinate condizioni. Io, comunque, preferirei evitare una situazione del genere per qualsiasi motivo.... mi immagino una bella stampa di giorni rovinata per una roba del genere 🥶

[eaman]

14 hours ago, Drvo said:

Quando stressi un hdd lo stressi in tutte le sue funzioni e prestazioni quindi: cache, velocità, ecc, sono tutte funzionalità prese in causa.

DRVO: il gcode come lo mandi alla stampante? Fai uno stream da riga di comando da un inode a un device seriale OPPURE lo carichi in un programma *slicer tipo Pronterface? Nel momento in cui apri il file in Pronterface lo hai gia' caricato in RAM, e prima di entrare in RAM e' in cache dell'OS e in cache dell'hd. Ma anche se tu facessi uno stream tu ci dovresti mettere proprio di cattiveria a basso livello per riuscire a far si che il kernel non lo carichi tutto in RAM subito.

Ve lo ripeto: potete avere dei rallentamenti a mandare dati a un microcontrollore ma questi sono dovuti alla *seriale, prettamente quella della scheda, non dalla lettura dei supporti di storaggio del PC. Il sistema operativo come diceva @Maso non centra, il vantaggio di usare GNU/Linux sul controller e' piu' che altro che puoi evitare di avere processi concorrenti che interferiscano con la stampa.

[Drvo]

23 minuti fa, eaman ha scritto:

DRVO: il gcode come lo mandi alla stampante? Fai uno stream da riga di comando da un inode a un device seriale OPPURE lo carichi in un programma *slicer tipo Pronterface? Nel momento in cui apri il file in Pronterface lo hai gia' caricato in RAM, e prima di entrare in RAM e' in cache dell'OS e in cache dell'hd. Ma anche se tu facessi uno stream tu ci dovresti mettere proprio di cattiveria a basso livello per riuscire a far si che il kernel non lo carichi tutto in RAM subito.

Ve lo ripeto: potete avere dei rallentamenti a mandare dati a un microcontrollore ma questi sono dovuti alla *seriale, prettamente quella della scheda, non dalla lettura dei supporti di storaggio del PC. Il sistema operativo come diceva @Maso non centra, il vantaggio di usare GNU/Linux sul controller e' piu' che altro che puoi evitare di avere processi concorrenti che interferiscano con la stampa.

Il gocode che ti genera e/o invia cura alla stampante è in streaming.... è la stampante che lo salva nel suo buffer e poi si va a pescare i vari gcode. In marlin ci sono anche delle variabili per aggirare eventuali crash dovuti ad un buffer settato al minimo indispensabile.