[cancellato]
Giann motivo per cui avevo escluso sophos purtroppo.
La versione home è gratuita. Non open. ma con licenza free-as-in-beer.
Giann motivo per cui avevo escluso sophos purtroppo.
La versione home è gratuita. Non open. ma con licenza free-as-in-beer.
[cancellato] più che altro BSD mi fa storcere il naso perché lo trovo "più indietro" rispetto a Linux, compatibilità hardware non ho avuto problemi per ora, però ad esempio gestire le PPPoE ancora in single core (correggetemi se sbaglio) (anche se è inutile per ora dato che ho una 100M è un problema non problema per me) e il fatto anche di non essere compatibile con cake ma solo con fq_codel (con cake su WRT mi ci son trovato divinamente, e mi pare di aver capito che può girare sul kernel linux ma non su BSD), mi lasciano un po' di amaro in bocca. Mi da quasi l'idea di qualcosa di inefficiente anche se magari non lo è.
[cancellato] ah non lo sapevo, allora magari mi faccio una prova su VM
gio79 assolutamente, ho una macchina che è li solo per quello, però WRT su x86 era instabile purtroppo, PFsense invece si lo metti li e a parte una strana instabilità con fq_codel e tanti torrent, e la mia stupidità (mentre facevo le prove per il Firewall ho fatto fare a Pfsense da server PPPoE e quando poi ho avviato un trasferimento è esploso tutto), va bene.
Giann , però ad esempio gestire le PPPoE ancora in single core (correggetemi se sbaglio)
In realtà quella è solo la configurazione di default che dipende dall'hashing hardware dei pacchetti che fanno le schede di rete per smistarle nelle loro code. C'è un meccanismo in base al quale i pacchetti vengono smistati sulle code della scheda dei in base all'hash che è fatto all'header IP (v4 o v6) dei pacchetti. Quando c'è il frame PPP fra Ethernet e IP, l'hash hardware non funziona e i pacchetti finiscono tutti nella stessa coda.
Di default (net.isr.dispatch=direct
), FreeBSD processa tutto il pacchetto in un singolo interrupt - in questo modo siccome un singolo core è associato ad una specifica coda, l'interrupt finisce chiamare sempre lo stesso core. Impostando net.isr.dispatch=deferred
l'interrupt si limita a prelevare il pacchetto e lo mette poi in una coda dalla quale possono prelevare tutti i core per completare l'elaborazione. Se non c'è PPPoE di mezzo è più efficiente il primo meccanismo, se c'è PPPoE conviene abilitare il secondo, se un core non ce la fa a starci dietro.
Giann perché lo trovo "più indietro" rispetto a Linux,
Sono tutte e due fimasti fermi indietro di 50 anni, ma questo è un altro discorso... il problema è che nessuno ormai osa più scrivere un OS moderno che non abbia un design vecchio di decenni.
Giann on essere compatibile con cake ma solo con fq_codel
Prima di fasciarsi la testa però è utile fare delle misure quantitative per vedere se il problema c'è sul serio nel tuo caso e quindi richiede una soluzione o il bufferbloat non avviene.
[cancellato] Prima di fasciarsi la testa però è utile fare delle misure quantitative per vedere se il problema c'è sul serio nel tuo caso e quindi richiede una soluzione o il bufferbloat non avviene.
Con FQ_codel diventa A+, però in alcuni casi crasha e ho notato che in console spuntano dei flowset_busy.
Mentre all'epoca col timhub e la ansuel con cake 0 problemi. E dovrebbe anche essere più efficiente lato cpu.
Che quella del mio thinclient AMD GX217GA fa schifo ma una 100M se la tiene su, e avendo anche AES-NI magari qualcosa per la VPN riesce a farla.
Poi il giorno che arriva la FTTH o che mi stufo del thinclient ho già pronto un optiplex con un i5 3a gen.
C'era un bug segnalato anni fa ma non sono mai state riportate informazioni utili ad una diagnosi (https://redmine.pfsense.org/issues/5383). Può essere che dipenda da qualche configurazioni specifica.
[cancellato] no fq_codel crasha solo se avvio troppi torrent quindi immagino magari sia per via del numero di connessioni?
Anche perché poi se non ho alcun torrent va bene.
Vabbé, allora te la cerchi
Scherzi a parte, non dovrebbe comunque crashare - se ci sono troppe connessioni non può fare miracoli e ci saranno dati nei buffer, ma non deve crashare. Stai usando ALTQ o altro? Con che schede di rete?
[cancellato] Vabbé, allora te la cerchi
Ah quello sempre
[cancellato] Scherzi a parte, non dovrebbe comunque crashare - se ci sono troppe connessioni non può fare miracoli e ci saranno dati nei buffer, ma non deve crashare. Stai usando ALTQ o altro? Con che schede di rete?
No l'ho impostato nei limiter e mi pare direttamente come fq_codel e codelq, la scheda di rete per la WAN è una intel 82574 e per la LAN una realtek non ricordo il modello .
Bisognerebbe provare con una configurazione diversa e vedere se non crasha. Poi Realtek e pfSense/BSD non vanno molto d'accordo con traffico elevato - ma dipende dal modello della scheda e dalla versione del driver.
[cancellato] eh lo so, anche pee questo mi piacerebbe magari provare un'alternativa basata su Linux (che anche loro non è che vadano molto d'accordo con realtek però è già migliore la situazione), infatti quando ho preso la scheda di rete aggiuntiva ho cercato la Intel e trovai questa che non mi ha mai dato un problema e messa per la LAN. Peccato solo che minipcie con 2 slot ce ne sono poche e costano uno sproposito altrimenti avrei usato la Intel per entrambe.
Informativa privacy
-
Informativa cookie
-
Termini e condizioni
-
Regolamento
-
Disclaimer
-
🏳️🌈
P.I. IT16712091004 - info@fibraclick.it
♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile