Newsgroup: it.comp.os.dibattiti
Titolo: Windows Scalable Networking Pack

Microsoft e altri stanno lavorando duramente per permettere ai pc di 
raggiungere e superare le prestazioni di sistemi di fascia molto più alta. 
Questa tecnologia di Scalable Networking combina hardware e software 
(Windows) con l'obiettivo di avere prestazioni sulla rete superiori.
http://www.microsoft.com/technet/itsolutions/network/snp/default.mspx
http://download.microsoft.com/download/8/5/9/859cb576-3959-4a33-b599-
ea21963593b8/SNPWhitepaper.doc
La prima volta che ne ho sentinto parlare era relativamente a Longhorn. E' 
interessante notare che è stata implementata anche su Windows 2003 e XP 
x64. Altro aspetto interessante è la combine sempre più stretta tra 
hardware e sistema operativo. Oltre all'uso intensivo di GPU, di memorie 
flash, di CPU multicore, ecc. ecc. già viste in altri versanti, in questo 
caso si parla anche di schede di rete "furbe". E' un trend interessante.
Di queste operazioni ne beneficieranno probabilmente in futuro anche Linux 
e MacOS. 
MS

 e MacOS. 
Linux supporta già TCP Segmentation Offload e Intel I/OAT.
Il TCP Offload Engine non c'è perché si visto che non da vantaggi
sostanziali a fronte degli svantaggi di far girare buona parte dello stack
TCP/IP in una scheda di rete.
http://lwn.net/Articles/148697/
http://lwn.net/Articles/152648/

 e MacOS. 
in che modo scusa?
ciao

 wrote in
news:1155383151.3...@m73g2000cwd.googlegroups.com
: 

Hardware e firmware migliori disponibili sul mercato. Adesso che MacOS gira 
sulla piattaforma Intel potrà accedere a questi risultati anche se dopo 
Microsoft. Quanto a Linux lo fa già da tempo.

Lorenzo Allegrucci <lor...@voyager.tux.lan> wrote in
news:pan.2006.08.12....@voyager.tux.lan: 

Le fonti da te citate sono interessanti ma mi sembra che espongano 
considerazioni non definitive e contrastanti rispetto a TOE. 
Comunque il senso della mia frase da te riportata era generale e non 
solamente legato allo stack di rete. C'è un processo in corso che 
consiste nel creare pc con sottounità sempre più intelligenti e/o 
specializzate in modo da distribuire il carico di lavoro. I sistemi 
operativi (in primis Windows Longhorn visto che Microsoft è uno dei 
leader di questo processo) useranno sempre più queste caratteristiche. Il 
paradosso è che la differenza tra Windows e MacOS sarà sempre meno 
marcata. E lo stesso secondo me sarà fra Windows Server e Linux. 
Questo poi metterà sotto stress i programmatori di applicazioni perchè 
per sfruttare molte di queste caratteristiche devi pensare in termini di 
multithreading , non blocking IO, ecc. ecc.
Insomma ci aspettano tempi molto interessanti (e spero remunerativi per 
noi professionisti) ;-). 

 marcata. E lo stesso secondo me sarà fra Windows Server e Linux.
si certo. Tutto questo se linus restera' in panciolle.
Piu' esattemente, mi metterei al sicuro e direi: la differenza tra Windows
di domani e Linux di oggi sara sempre meno marcata.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 (Windows) con l'obiettivo di avere prestazioni sulla rete superiori.
LOL. ... ho un dubbio.
Lo stack TCP di *BSD funzionava bene e lavorava tranquillamente a 100
megabit. Quello Linux doveva essere patchato (magari ora e' stato gia'
risolto).
Mi viene il dubbio che windows soffra ancora di quei problemi dei quali
soffriva linux a quel tempo. Pertanto tu lo chiami "Scalable Networking"
ma, per rendere meglio l'idea lo chiamerei "Working Networking".


Max_Adamo wrote:
:: si certo. Tutto questo se linus restera' in panciolle.
Potrebbe anche passar a miglior vita, come tutti noi del resto....
:: Piu' esattemente, mi metterei al sicuro e direi: la differenza tra
:: Windows di domani e Linux di oggi sara sempre meno marcata.
Sarà invece un differenza notevole. Più grande di quella di oggi.
IMHO.
Saluti.

 
Veramente io la intendevo al contrario. Dal mio punto di vista (Vista?) 
Linux è in svantaggio. Il fatto di avere vincoli hardware sempre più 
stringenti costringerà i sistemi a essere sempre più simili. 
MS

 Networking". 
Questo è un commento gratuito. Qua comunque stiamo parlando di bande più 
consistenti. E il confronto non è fra sistemi su pc ma fra pc e sistemi 
diversi di fascia più alta. Questo tipo di tecnologie restringerà ancora 
più il campo di azione dei sistemi intermedi.
MS

 Potrebbe anche passar a miglior vita, come tutti noi del resto....
Al di la` del discorso in se questo e` un problema davvero interessante
secondo me in quanto non e` ancora accaduto nulla di simile per alcun
progetto informatico appena diffuso (d'altronde l'informatica e` tanto
sviluppata da appena 20 anni).
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 l'informatica e` tanto sviluppata da appena 20 anni).
Oddio, direi che il problema puo' essersi anche presentato, ma in una
forma inaspettata. Per spiegarmi meglio, eccetto i progetti open source
in cui e' ben definita una autorita' fisica (e.g. il kernel Linux), i
progetti closed source sono di appannaggio di aziende distinte (e
quindi vi e' una autorita' giuridica). Attualmente, solo nel primo caso
(autorita' fisica per i progetti open source) il problema e' una
incognita
Enrico

 consistenti.
Prima di parlare di bande piu' consistenti chiediti: Windows lavora
veramente a 100mbit?
Obiettivamente, non ho informazioni precise su windows, ma ho fortissimi
sospetti.


Max_Adamo wrote:
:: Prima di parlare di bande piu' consistenti chiediti: Windows lavora
:: veramente a 100mbit?
Beh, qui a casa ho tutta la rete ad 1 Gb. Facendo un xcopy da una macchina 
all'altra
l'indicatore di uso della banda segna un uso pari al 25/27%. Quindi ben 
oltre i 100Mbit.
E credo che il collo di bottiglia non sia lo stack di rete dato che i dischi 
sono tutti ATA/100.
Saluti.

 Hardware e firmware migliori disponibili sul mercato.
non sono cosě sicuro.....
Se vedi gli ultimi driver che intel ha rilasciato per le schede di rete
wifi, hanno un firmware colsed source che fa schifetto.... Driver che č
stato rifatto dal team di openbsd e che funziona con meno righe di
codice e senza processi aggiuntivi in userspace.
http://kerneltrap.org/node/6650

 risolto).
prego? hai un link? come è che non me ne sono mai accorto?



25/27% ... mhhh ... consentimi di sospettare ancora.
senza nessuna verve polemica: io rifarei la stessa prova con hardware a
100mbit.




E' una cosa un po' vecchia .... dove te lo pesco :) Prova a googolare in
base alle cosa che ti ho scritto. 
Ho letto un confronto Linux vs. BSD.... ma non ti preoccupare, Linux non
ne usciva malconcio.


Max_Adamo wrote:
:: 25/27% ... mhhh ... consentimi di sospettare ancora.
:: senza nessuna verve polemica: io rifarei la stessa prova con
:: hardware a 100mbit.
L'XCOPY è di un file di 5 Gb.
Con l'hardware a 100 la banda giustamente segna 50/60% come ovvio 
trattandosi di Ethernet.



Esatto.
ammesso che sia vero quello che ho letto, questo e' proprio quello a
cui mi riferisco. Certe fonti dicono che BSD lavora al 100% a 100 mbit, e
non al 50%. Linux, per arrivare a quel livello doveva essere patchato.
Cerco conferme: non ho BSD e a casa uso il wireless per il notebook.


Max_Adamo wrote:
:: Esatto.
:: ammesso che sia vero quello che ho letto, questo e' proprio quello a
:: cui mi riferisco. Certe fonti dicono che BSD lavora al 100% a 100
:: mbit,
Su una rete Token Ring forse. Su una Ethernet non può. Fisicamente.
Se ti va di culo arrivi al 80/85%.



La Token Ring che va a 100mbit la vedo un po' dura visto che, se non
ricordo male, va a 4 o 16 mbit (ok, tu parlavi di percentuale massima
utilizzabile). Chiaramente errori e collisioni fanno si che tu non possa
arrivare a 100% sulla ethernet, ma se non e' 100, puo' essere 80, 85,
90.... e non 50.
Cmq la Token Ring avra' anch'esa i suoi delay: devi aspettare il token, il
token si puo' perdere (tutto calcolato anche li', come le collisioni).
Ecco perche' parlavo di "working networking", piuttosto che di "scalabel
networking".... ma non ho ancora le prove che quello che dico su BSD e'
vero.


 ne usciva malconcio.
Sono tool che analizzano il codice senza alcun intervento umano, per non
parlare del fatto che stai confrontando un kernel con un sistema operativo
completo (o non ho la minima idea di come facciano ad isolare il kernel dal
core) che, tra le tante cose, include un merdaio di tool normalmente inclusi
nel malsano concetto di "distro".
Gli sviluppatori di FreeBSD, che magari conoscono il loro codice un po' meglio
di un "tool", dicono che i bug effettivi sono molto pochi, piů o meno la
stessa cosa che hanno detto gli sviluppatori del kernel Linux. Si parla di 5
bug trovati grazie a Coverity, putacaso. 
Se anzichč postare link a caso tu ti informassi 3 secondi prima eviteresti 
queste cagate, ma immagino che un ometto che finora si č fatto segare *5* 
account di posta dal sottoscritto non capisca tali mirabolanti concetti.
Se cortesemente ti scegli un merdoso account e usi quello magari riesco a
killarti. Se morphi ogni 3 post č un po' difficile. Sei un troll, si č capito,
non servono ulteriori prove.
Addio :)
  ngw

 Cerco conferme: non ho BSD e a casa uso il wireless per il notebook.
Non so a quali fonti ti riferisci ma anni fa feci un test con lmbench,
tcp_bw [1] per la precisione, collegamento cross desktop-notebook 100Mbit,
Linux kernel 2.4.  Banda misurata: 11.6 MByte/s (circa, non ricordo con
esattezza), ovvero 92.8 % della banda disponibile. Se togli l'overhead di
protocollo dell'ethernet, IP e TCP dovresti arrivare vicino al 100%. E'
una cosa normale, non credo ci siano differenze significative tra i
diversi OS. Potrebbero essercene a 1Gbit o a 10Gbit se la cpu ha un pò il
fiato corto.
[1] tpc_bw misura la banda direttamente, senza toccare il fs.

 dico su BSD e' vero.
Sinceramente a me pare che Windows vada già molto bene in questo senso. I 
colli di bottiglia spesso sono altri (vedi aneddoto). Sempre per 
esperienza i colli di bottiglia che abbiamo trovato in giro anche nelle 
nostre applicazioni (e ne abbiamo fatte alcune veramente grosse) sono il 
numero di transazioni massimo gestibili dagli application server (qua 
Windows non è affatto male soprattutto se sai accordarlo). A questo 
proposito ci sono piattaforme che veramente fanno ombra ai pc (per 
esempio, costo a parte, un S/390 con zOS e Linux sopra) ma l'obiettivo di 
Microsoft, Intel e soci è diminuire sempre più questo distacco (e ci 
stanno riuscendo benissimo). 
MS

 colli di bottiglia spesso sono altri (vedi aneddoto). 
"a me pare che vada bene" non e' una valutazione scientificamente
accettabile. Che ne dici? ;) Bisognerebbe veramente vedere come lavora lo
stack di BSD e lo stack patchato di Linux. A quel punto potremmo
fare meglio tutti i nostri blablablabla. Io questa cosa l'ho semplicemente
letta e riportata e non mi sento di metterci la mano sul fuoco, pero' dire
"a me pare che..." non va molto.


 diversi OS.
Come no? 
mi stai confermando tutto cio che ho sostenuto fin qui.
Leggi i post.
GdG ha scritto che il suo windows arriva massimo al 50%, tu mi dici che il
tuo Linux arriva al 90%.


 Sono tool che
mi sa che sei nel thread sbagliato :) Controlla.


 risolto).
Ma sei sicuro? Giusto per chiarezza ho un server (2-way) in azienda con
4 schede di rete ad 1 GB/s (tutto il mio network č cablato ad 1 GB) ed č
il mio router centrale... mi forwarda pacchetti tra 4 differenti
segmenti riuscendo, sotto carico massimo (massimo traffico da e per
tutti i segmenti) a mantenermi prestazioni da circa 700 Mbit...
6 anni fa per la stessa cosa usavo 4 schede di rete a 100 Mbit e sempre
Linux come s.o. per il mio router (iptables e forwarding a palla) e
l'hardware all'epoca era un misero celeron 466 con 64 Mbit di memoria
RAM... e riusciva a tenermi il traffico...

 ne usciva malconcio.
tra le cose vecchie ho visto solo un articolo di migliormento di netbsd
della patch che citi nemmeno l'obra. E francamente a 100 mbit ci sono
andato da sempre, o meglio, da quando ho avuto la rete a casa a 100
mbit. :-)

 Ma sei sicuro?
tutto chiarito.
Linux usa il 90% della banda
windows usa il 50% della banda


 windows usa il 50% della banda
What do you mean? ;)

 windows usa il 50% della banda
Beh, se consideri che il mio router gestisce 4 nic da 1 GB/s
garantendomi 700 MB/s per segmento... immagina che con una sola nic
avresti il 100%... 



I mean, nobody understands what I am saying :)
tutti mi avete risposto dicendo: "eh ma il mio linux .."
Ho detto di aver letto una vecchia recensione che diceva di questo
problema del passato con linux e ho aggiunto che e' probabile che oggi non
sia piu' cosi'.
Il dubbio che mi e' sorto, spontaneo, e' che Windows avrebbe potuto avere
tutt'oggi quel problema. Qualcuno qui dentro mi ha dato una involontaria
conferma di cio'.
GdG ha scritto:
"con la Gigabit ottengo un transfer-rate del 25% della banda e che il collo
di dottiglia erano probabilmente i dischi ATA." 
Gli ho detto di provare su fast-ethernet e mi ha detto di aver raggiunto
il 50% della banda. 




va bene hai ragione tu.
Ho letto un sito che non esiste.
sinceramente quando scrivete queste cose non so piu' cosa rispondervi.
Ho detto di aver letto una cosa. Un conto e' dire che quella cosa potrebbe
essere sbagliata, imprecisa, un altro conto e' dire che non esiste, o che
se esiste non esiste quella cosa che ho citato io.
lo scrivo a chiare lettere:
=> C'ERA UN LINK DI UN SITO PER SCARICARE LA PATCH PER LINUX.
=> PUO' DARSI CHE SI TRATTA DI INFORMAZIONI OBSOLETE.
=> GIURO CHE ESISTE: NON HO LE TRAVEGGOLE.


Max_Adamo wrote:
di cio'.
::
:: GdG ha scritto:
:: "con la Gigabit ottengo un transfer-rate del 25% della banda e che
:: il collo di dottiglia erano probabilmente i dischi ATA."
:: Gli ho detto di provare su fast-ethernetB e mi ha detto di aver
:: raggiunto il 50% della banda.
Sempre usando per l'operazione la copia di files da svariati Giga.
Significa che devi considerare l'overhead per la lettura/scrittura e 
dell'antivirus
attivo.
Forse cerchi questa roba qua.
http://www.mindcraft.com/whitepapers/openbench1.html



Gabriele,
Che dobbiamo farci con 'sta cosa? ==>>>>  June 30,1999, Linux
kernel 2.2.10, Windows NT 4.0 ... E' valido solo come esempio su come si
organizza un benchmark? Giusto? Comunque sia, noi non parliamo di
throughput di un file-server. Semplice trasferimento, anche di un solo
file da A a B.
Poi: l'antivirus potrebbe creare un collo di bottiglia durante la
scrittura su disco? chiaramente non so che tecnologia usi per i dischi.
Comunque, senza troppi discorsi, disattiva l'antivirus e rifai la prova :)
p.s.: guarda che oggi guardavo un benchmark tra webserver linux e
microsoft.... stavolta si tratta di win2003 e linux 2.6. Lo trovi su
Slashdot, ma non so se ti convenga cercarlo ;)


Max_Adamo wrote:
::
:: p.s.: guarda che oggi guardavo un benchmark tra webserver linux e
:: microsoft.... stavolta si tratta di win2003 e linux 2.6. Lo trovi su
:: Slashdot, ma non so se ti convenga cercarlo ;)
Guarda che le gare a chi ce lo ha più lungo io ho smesso di farle tanti anni 
fa....
Io ci devo lavorà e portà a caso lo stipendio co sti trabbicoli.
Saluti.

 Io ci devo lavorà e portà a casa lo stipendio co sti trabbicoli.
Gabriele,
siamo nella stessa barca :)


 => GIURO CHE ESISTE: NON HO LE TRAVEGGOLE.
non ti incavolare, solo che alla tua buona fede di "l'ho visto" io
oppongo quello che ho trovato cercando.
Un "sei proprio sicuro?" almeno lo devi tollerare.....

 Io ci devo lavorà e portà a caso lo stipendio co sti trabbicoli.
:-D



Sicuro di aver letto quello che riportato qui? SI SONO SICURO.
Sicuro che sia vero cio' che ho letto? NO. NON SONO SICURO (e non trovo
piu' la fonte).


 
Sostengo che i colli di bottiglia spesso non sono nella LAN. 
Comunque empiricamente ho fatto questa prova a casa mia: ho copiato 1 GB 
di file vari (da 200 a 500 MB) tra il mio sistema XP MCE SP2 
(autocostruito Shuttle XPC con NForce3 con scheda LAN incorporata, 
processore Athlon XP 3200, 1 GB di RAM, disco SATA1) e il portatile 
aziendale XP Tablet PC SP2 (un  Toshiba Portege M200 con Centrino 1.6 GHz 
e scheda LAN Intel incorporata, disco IDE da 5400 giri, 2 GB di RAM). Lo 
switch è uno Zyxel da 5 porte (motivo della scelta: è pesante e non si 
sposta). Oltre a questi dispositivi c'erano in rete l'access point 
LinkSys (preso perchè ha Linux dentro - uno spasso) e un'altro portatile. 
Con un Total Commander ultima versione (a cui ho dato un po' di buffer) 
ho trasferito circa un GB di file vari (tra cui uno da 100 MB e un'altro 
da 400 MB). Velocità ottenute tra i 60 e i 70 Mb/s. Sicuramente il 90 
Mb/s me li sogno con la mia rete e con le schede di queste macchine.
Appena ho tempo voglio provare con due macchine Vista.
Bye. MS.

 
Va be adesso cerchiamo di non "girare il mondo". Queste cose esistono, 
funzionano già da anni. Noi in azienda abbiamo varie macchine con schede 
  TOE tipo questa: 
http://www.sbei.com/support_files/datasheets/toePCI-2Gx.pdf
 e vanno alla 
grande.
Windows non le supporta, ha deciso di iniziarle a supportare, la notizia 
è solo questa.
La versione giusta è: ci sono soluzioni del genere che funzionano 
perfettamente (da anni) con AIX, SOlaris, Linux ora Windows ci sta 
lavorando sopra per ULTIMA, probabilmente in futuro le supporterà.
Entrando nel dettaglio poi non sempre queste cose sono risolutive perchè 
  i problemi delle reti non sono quasi mai di throughput e di cicli di 
cpu usati.
Ciao

 Cerco conferme: non ho BSD e a casa uso il wireless per il notebook.
Scusa, ma al 100% non ci arriva in alcun modo. Come la mettiamo con
l'overhead dei protocolli e con gli errori?

Giulio Severini wrote:
::: Esatto.

E' notorio che Unix e derivati vanno oltre i normali limiti fisici.
Tra poco arriverà al 200%.
Saluti.

 cpu usati.
Questo lo sostengo anche io ma l'idea è interessante soprattutto i 
prospettiva di bande larghissime.
MS