Na most elvileg kihúzott állapotban is pingelhető kellene, hogy legyen, de nem az a win7 alatt. Találtam közben egy 250-es SSD-t, úgyhogy holnap majd felteszek rá egy FreeBSD-t, aztán meglátjuk, azzal hogy szuperál.

Buliban hasznos! =]

Érdemes lenne ránézni a firmware kompatibilitási listára is. Driver verzióhoz van megadva a kompatibilis firmware.

Ja, én is erre gondoltam, hogy az nem passzol, de nem tudok mit csinálni vele. Nem fogom a firmware-t régebbi verzióra állítani. Inkább megnézem másik OS-el. Ez a win7 úgyis elavult, és csak azért van fent, hogy Windows-os programokat futtatni tudjak.

Buliban hasznos! =]

No felkínlódtam valahogy az asztali gépemre is a FreeBSD-t. Megnéztem, eth mode-ban vannak a kártyák, kaptak IP címeket, tudják pingelni egymást.

Az első iperf3 eredmények ilyenek:

iperf3 -c 192.168.13.13 -p 5002
Connecting to host 192.168.13.13, port 5002
[ 5] local 192.168.13.14 port 62372 connected to 192.168.13.13 port 5002
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 667 MBytes 5.59 Gbits/sec 0 1.57 MBytes
[ 5] 1.00-2.00 sec 698 MBytes 5.86 Gbits/sec 0 1.58 MBytes
[ 5] 2.00-3.00 sec 698 MBytes 5.85 Gbits/sec 0 1.58 MBytes
[ 5] 3.00-4.00 sec 698 MBytes 5.85 Gbits/sec 0 1.58 MBytes
[ 5] 4.00-5.00 sec 698 MBytes 5.85 Gbits/sec 0 1.58 MBytes
[ 5] 5.00-6.00 sec 698 MBytes 5.86 Gbits/sec 0 1.58 MBytes
[ 5] 6.00-7.00 sec 698 MBytes 5.85 Gbits/sec 0 1.58 MBytes
[ 5] 7.00-8.00 sec 698 MBytes 5.86 Gbits/sec 0 1.59 MBytes
[ 5] 8.00-9.00 sec 698 MBytes 5.85 Gbits/sec 0 1.59 MBytes
[ 5] 9.00-10.00 sec 698 MBytes 5.85 Gbits/sec 0 1.59 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 6.79 GBytes 5.83 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 6.78 GBytes 5.83 Gbits/sec receiver

iperf3 -c 192.168.13.13 -p 5002 -R
Connecting to host 192.168.13.13, port 5002
Reverse mode, remote host 192.168.13.13 is sending
[ 5] local 192.168.13.14 port 32062 connected to 192.168.13.13 port 5002
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 446 MBytes 3.74 Gbits/sec
[ 5] 1.00-2.00 sec 473 MBytes 3.97 Gbits/sec
[ 5] 2.00-3.00 sec 426 MBytes 3.57 Gbits/sec
[ 5] 3.00-4.00 sec 410 MBytes 3.44 Gbits/sec
[ 5] 4.00-5.00 sec 411 MBytes 3.45 Gbits/sec
[ 5] 5.00-6.00 sec 411 MBytes 3.45 Gbits/sec
[ 5] 6.00-7.00 sec 412 MBytes 3.46 Gbits/sec
[ 5] 7.00-8.00 sec 399 MBytes 3.34 Gbits/sec
[ 5] 8.00-9.00 sec 397 MBytes 3.33 Gbits/sec
[ 5] 9.00-10.00 sec 393 MBytes 3.30 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 4.08 GBytes 3.51 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 4.08 GBytes 3.50 Gbits/sec receiver

Én ebből úgy gondolom, hogy az SSD-k írási sebessége szab határt neki. Mindenesetre már így is 1 Gbps felett vagyok, úgyhogy bódottá van. Majd utánanézek, hogy hogyan tudok memóriából memóriába küldeni, gondolom akkor meglesz a 10 körüli érték. Utána meg jöhet az optikai kábel a DAC helyett meg az optikai keystone-os aljzat szerelése hozzá. Az is lesz valami...

Buliban hasznos! =]

Ahogy nézem memóriában dolgozik by default, akkor viszont nem tudom mi fogja vissza ennyire. Bármi ötlet?

Egyébként mértem többször következetesen ugyanezeket az értékeket hozza fel és le.

[ Szerkesztve ]

Buliban hasznos! =]

No a pcről a szerverre 3.9 körül megy, a szerverről a pc-re meg 5.8-al. Ami kiderült eddig, hogy nem számít, hogy a kábel melyik végét hova dugom és az sem számít, hogy melyik kártya van bent melyik gépben. Ezek alapján nekem úgy tűnik, hogy a gépekkel vagy azok beállításaival van valami gond, és a kártyák és a DAC kábel megfelelően működik. Ami még feltűnt, hogy volt néhány retransmit, illetve, hogy a PC-ben jóval hidegebb volt a kártya, mint a szerverben, de felette van az RX580 hűtője, úgyhogy gondolom amiatt lehetett. Fogalmam sincs innen hova tovább, még tudok CPU terhelést nézni mérés közben, de kb. ennyi. A PC-ben elképzelhető, hogy hibás az alaplap vagy a processzor, mert a B memória csatorna nem működik rajta. Már vettem egy Pentium G3250-et egy ezresért, hogy kizárjam az alaplap hibát ebből a szempontból. Megnézem, hogy van e pasztám, aztán ma nekiesek és ha bírja a Pentium is, akkor mérek azzal is egyet. A szervernél eddig nem volt semmi anomália, annak elvileg rendben kéne lennie hardver szempontból.

Buliban hasznos! =]

tudod a kliens oldalon csokkenteni a prociterhelest a --repeating-payload kapcsoloval. a -P kapcsoloval pedig a parhuzamositast, az is segithet.
szoval a negy valtozat amirol beszeltem az kb igy nez ki nalam:
iperf3 -c 192.168.106.1 -O 2 -t 20 --repeating-payload
iperf3 -c 192.168.106.1 -O 2 -t 20 -R --repeating-payload
iperf3 -c 192.168.106.1 -O 2 -P 128 -t 20 --repeating-payload
iperf3 -c 192.168.106.1 -O 2 -P 128 -t 20 -R --repeating-payload 

szerk:
ha nagyon csucsra akarod jaratni az iperf-et, akkor indithatsz tobb szervert is, mondjuk mas-mas porton es a masik oldalon tobb klienst egyszerre, de ez mar szorszal-hasogatas. illetve megnezheted meg h a scheduler pakolgatja-e az iperf-et, pineles is segithet (taskset).
es ha nagyon bedurvulsz, johet az isolcpu

[ Szerkesztve ]

Beraktam a Pentiumot a core i5 helyett. 63% upload, 119% download az értékei a Pentiumnak és 95% upload, 43% download a core i5-nek. Elvileg az utóbbinak egy magon is többet kéne tudnia, és mégse. A sebességek is érdekesek 2.9 upload és 5.8 download a Pentium és 3.8 upload, 5.8 download a core i5. Szóval lehet, hogy nem megy fel maxra a CPU a pentiumnál, és az átviteli sebesség is amiatt gyengébb. Azt mondjuk nem értem, hogy miért nem járatja maxra, ha ennyire CPU függő a dolog. Mindjárt megnézem párhuzamosan is, ahogy írtad, meg tesztelem a dual channel memory-t végre, hogy működik e másik CPU-val vagy az alaplap a rossz a PC-ben.

Buliban hasznos! =]

nezhetsz halokartya statisztikat is, annak a szamlaloi is segithetnek, ha pl nem sikerul foglalni csomagokat vagy dobalas van azert, mert nem fert bele pl az rx queue-ba a csomag a lassu kihuzgalas miatt, stb.
illetve a netstat is segit, ha van pl retransmission vagy reordering, akkor az mind lassit.
ha pedig a mindenfele kernel taszkok miatt azert dobalsz, mert idoszakosan felgyulnek a csomagok az rx queue-ban, akkor annak a meretet is felveheted a tipikus 1k-rol (v 512, drivere valogatja) akar 4k-ra is. altalaban inkabb nem javasolt, mert ezzel okozhatsz mas problemakat is, de a csupasz teljesitmeny-mereshez jo.

[ Szerkesztve ]

No, a PC-ről küldve a "-P 2" növelii 4.7-re a sebességet és nő a CPU terhelés is 95%-ra. A szerveren viszont csökken tőle 5.8-ról 5.5-re a sebesség és ott is megnő 90%-ra a CPU terhelés. A "-P" további növelése nem változtat semmin. A --repeating-payload sem jár komolyabb hatással. Akkor ezek szerint 1 magon gyenge egy 3.4 GHz-es processzor, hogy kitolja a 10 Gbps-t? Ilyen van a szerverben: [link], ilyenek meg a PC-ben: [link] [link] Esetleg valami más van a dologban?

Buliban hasznos! =]

hat tesztelj udp-vel az csak megy mint orult, nem zavarjak ilyen uri huncutsagok. nem tudom netcat mennyit bir, de az iperf is tudja ( -u )

Hát egyelőre csak annyi látszik, hogy az iperf3 ír retransmitet néha. Ez lehet a jele annak, hogy eldobál csomagokat, ahogy írod vagy eleve van valami átviteli hiba a két kártya között?

Ránéztem most "netstat -i"-vel is, és idrop-ot ír mérésenként kevesebb, mint 100-at. Nekem nem tűnik annyira jelentősnek, ha 10 millió csomagból 10 elveszik. Mértem most többet is, és fura. A pc-vel ha küldök, akkor egyszer 2.8, másszor 4.7 a sebesség, és a processzor terhelés is ennek a függvényében változik. Mértem egyszer 6.0-t is vele eldobott csomag nélkül, de azt nem sikerült megismételni.

Na most ami nekem roppant gyanús, hogy 6.0 körül maxol ki mindkét irányba az eddigiek alapján, ami a SATA3 max sebesség...

Buliban hasznos! =]

es mire gondolsz, hogy johet a kepbe a sata?
a dobott csomagok szama tenyleg kicsi, attol nem kene leessen ennyire a sebesseg, de nagyban fugg persze attol is h hol/milyen csomagot dobott, epp mekkora a tcp ablak, stb.
illetve szoktak ezzel a kartyaval masok merni nagyobb savszelt?

Megnéztem UDP-vel, de fura. Nálad működik rendesen vele? Nálam 1.05 Mbps-t küld, ha -P 128-at adok neki, akkor 128x1.05Mbps-t. Bugosnak néz ki...

Buliban hasznos! =]

Hát nem tudom, hogy szoktak e. Állítólag 10-et simán hoznia kellene, és olyan, hogy 10-re van lebutítva szoftveresen, és 40-et is tud, ha a firmware-t megmókoljuk. Aztán lehet, hogy hamis, de elég komoly munka olyan hamisítványt legyártani, ami elmegy a gyári driverrel, amiatt nem gondolnám...

Mások írják, hogy 8-9 körül simán megy nekik mindenféle külön iperf kapcsoló nélkül. Elvileg valami interruption moderation, ami lehúzhatja ennyire, mindjárt megnézem.

Buliban hasznos! =]

igen, be lehet allitva az is h mennyi interraptot engedjen, illetve vannak driverek amik atvaltanak interrupt mod-bol poll modra nagy pps eseten (nemtom mlx driver is ilyen-e).

nem bugos, fix bitrate streamenkent allitsd nagyobbra
-b, --bitrate n[KM]
set target bitrate to n bits/sec (default 1 Mbit/sec for UDP,
unlimited for TCP/SCTP). If there are multiple streams (-P
flag), the throughput limit is applied separately to each
stream. You can also add a '/' and a number to the bitrate
specifier. This is called "burst mode". It will send the given
number of packets without pausing, even if that temporarily ex‐
ceeds the specified throughput limit. Setting the target bi‐
trate to 0 will disable bitrate limits (particularly useful for
UDP tests). This throughput limit is implemented internally in‐
side iperf3, and is available on all platforms. Compare with
the --fq-rate flag. This option replaces the --bandwidth flag,
which is now deprecated but (at least for now) still accepted.

Kipróbáltam az interruption moderation kikapcsolásával, úgy se lett jobb. Majd még tesztelem több szerverrel és egy Ubuntuval is, csak hogy kizárjak minden eshetőséget, de egyelőre elég nagy csalódás ez a kártya. Ha stabilan hozná az 5 feletti értékeket, akkor még azt mondanám jól van, de így... :S

Buliban hasznos! =]

Köszi! Ezzel 5.2 a PC->S és 5.8 az S->PC fixen. A processzor felmegy 100% környékére a küldő gépen, úgyhogy szinte biztosan az fogja vissza mindkét irányba. Majd megnézem, hátha a Linux-hoz jobb driver van, mint FreeBSD-hez. Meg kipróbálom több szerverrel is mindjárt, hátha több magon hozható.

[ Szerkesztve ]

Buliban hasznos! =]

FTP-vel 240 és 340 MB/s-al mennek a letöltések, ami olyan 2-3 Gbps. Az 1 Gbps-nél végülis jobb, de szerettem volna elérni legalább az 5-öt. Próbáltam párhuzamosan két iperf szervert, de azt írta a másodiknál, hogy a cím használatban van, meg hogy unable to write stream socket, no buffer space available. Na nekem mára ennyi. Holnap megnézem Ubuntuval, aztán eldöntöm, hogy visszaküldjem e. A mostaniak alapján úgy tűnik, hogy komoly erőgép kellene ahhoz, hogy ezzel a kártyával 10-et lehessen hozni, annyira eszi a processzort. Gondolom nem véletlen ennyire olcsó.

[ Szerkesztve ]

Buliban hasznos! =]

ezt azert meg bongeszd at sztem ha nem lattad: mlx tuning guide

szerk: az iperf szervert biztos mas-mas portokkal vagy mas-mas ip-vel inditottad?

[ Szerkesztve ]

A port az mas volt, nem tudom az IP hogy lehetne mas. Ok, megnezem holnap, de nagy remenyeim mar nincsenek ezzel kapcsolatban.

Kozben megneztem a memoriat is, az alaplapban biztosan ki van egve valami, mert a masik processzorral sem indul, ha a 3-as slotba atrakom a memoriat a 2-esbol. Elkepzelheto, hogy mas resze is serult a lapnak. Nem tudom ez befolyasol e erdemben barmit. Marmint amikor a szerver kuldi annal is 100% CPU van, tehat ott is ugy tunik, hogy a gep fogy el, es a kartya tudna tobbet is. Majd veszek bele uj lapot, de igy unnepek korul franc tudja mikorra jon meg.

Buliban hasznos! =]

Kozben valaszoltak. A 8.5Gbps elerheto vele egy s2011-es lappal, szoval nem a FreeBSD vagy a driver a hibas jo esellyel, es elvileg a CPU is eleg kene, hogy legyen mindket gepben, megse az. [link]

[ Szerkesztve ]

Buliban hasznos! =]

ip ugy lehet mas, ha vagy hozzarendelsz egy porthoz tobb ip-t vagy tobb porton dugod oket szembe vagy csinalsz vf-eket.

udp-vel egyelore nekem sem egy nagy eresztes, kell 5 iperf ahhoz h menjen:
root@myclient:~# cat multiperfudp.sh
#!/bin/bash
iperf3 -c 192.168.106.1 -O 2 -t 20 -u -b 1.5G --repeating-payload -p 5201 -Z &
iperf3 -c 192.168.106.1 -O 2 -t 20 -u -b 1.5G --repeating-payload -p 6000 -Z &
iperf3 -c 192.168.106.1 -O 2 -t 20 -u -b 1.5G --repeating-payload -p 7000 -Z &
iperf3 -c 192.168.106.1 -O 2 -t 20 -u -b 1.5G --repeating-payload -p 8000 -Z &
iperf3 -c 192.168.106.1 -O 2 -t 20 -u -b 1.5G --repeating-payload -p 9000 -Z &
egyetlen udp-s iperf tud nalam kb 2.07G-t, azert allitottam 1.5-re. ezeket a kernel szetszorja igy, atjon nalam 7.5G. szoval minden HT-ra fellohetsz egyet a kliensen, akkor ezek valamennyire skalazodnak.
a tuloldalon persze siman inditottam tobb iperf3 -s -p xxxx szervert.

[ Szerkesztve ]

En azt nezem, hogy az egyik lapon pcie3 x4 [link] a masodik foglalat, a masikon meg pcie2 x2 [link]. Na most a kartyak x8-asak. A szabvany szerint pcie3 x1 = 8Gbps, pcie2 x1 = 4 Gbps. Ugyhogy a z97-p 8-nal nem is tud tobbet akarhogy tuningolom...A szerverben az msi-nel meg van esely tobbre, de nem tudom, hogy x8 kene e max sebesseghez vagy eleg neki az x4. Elvileg maga a kartya pcie3, szoval az x4 eleg kene, hogy legyen neki 30-hoz is, ha innen nezzuk. Kell egy jobb alaplap a PC-be, de nem nagyon talalni mar s1150-es ATX lapokat. Mikro ATX meg letezik esetleg, es az is max pcie2 x4-es a masodik foglalatra. Es akkor meg mindig nem tudom, hogy a core i5 CPU jo e vagy az is hibas, es tok feleslegesen veszek neki uj lapot. Na mindegy, ellocsolok erre is par tizest, aztan majd kiderul.

[ Szerkesztve ]

Buliban hasznos! =]

a gen3 x4 boven eleg.
gen2 x2 meg boven nem ott a 6-7G eletszeru.

Ja. Megprobalok apron venni egy lapot, de ez mar nem mai technologia, nehez lesz olyat talalni, ami nem szinten kuka. Teljesen beujitani most nem igazan akarok, de majd meg atgondolom.

Buliban hasznos! =]

szerintem az a 6Gbps gyonyoru elorelepes az 1Gbps-hez kepest. foleg ha regebbi vasakkal dolgozol, akkor a tipikus applikaciok sem fogjak tudni kihajtani, kiveve az ilyen masolas dolgokat.

szerk: amikor nem a pcie korlatoz, akkor a korabban linkelt mellanox-os guide meg mindig tud jo tippeket.

[ Szerkesztve ]

Nezd meg alaposan a cpu foglalatot (nagyitoval, vagy zoomolj ra mobilon).
Az is okozhatja a dual channel hianyat, ha ferde 1-2 lab.
A procinak nem kellene limitalnia, hiszen ezer eve lehet szerverekbe 10 gigas kartyat pakolni, es ott nem ritka, hogy 2 ghz-en futnak a magok,a gepre meg feldobalnak 5-10 VM-et.
Raadasul te meg csak siman masolgatsz a gepek kozott, a valoban cpu igenyes dolgok,mint a natolas, firewall csak ezutan jonne.

[ Szerkesztve ]

Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben

A kártyának mennie kéne rendesen, ugyanez nálam:

Az egyik oldalon egy i3-7100, 8GB ram, debian alapon omv, két darab 860evo 1TB raid0-ban, smb megosztással. A másik oldalon egy I7-8700, 32GB ram, 970evo 500GB, win10. A forgalmat egy Mikrotik CCR2004 vezényli, a nas dac kábellel, a pc pedig dupla lc-lc kábellel, SFP-10G-SR optikai modulokkal csatlakoznak. Kb ezt a tempót tudja a két raid0-s ssd, a cpu még a nas-ban sem fogy el az smb ellenére sem.

Koszi, akkor ezt legalabb tisztaztuk. En is ugy gondoltam, hogy nem kell neki sok CPU, nem ertem miert megy fel nekem 100%-ra, de majd az alaplap csere utan kiderul.

Buliban hasznos! =]

biztosan 2.5G-sek a lan portok is? Nekem a kép alapján nem úgy tűnik. (legalábbis franc tudja, hogy kell azt értelmezni, hogy 2.5G~WAN/LAN1~1G.
(kínaiul nem tudok, a logikájuk furcsa, google translate meg nem tud mit kezdeni a képekkel)

szerk: tech specnél 1db 2.5G-t írnak. [link] (persze ez is kép )

szerk2: megfejtettem.
- van 1db 2.5G port, ez használható WAN/LAN-nak. (kék)
- van 1db 1G-s WAN/LAN port (LAN1),
- és van 2db sima 1G-s LAN port. (LAN2, LAN3)
Hát ez lópikula.

[ Szerkesztve ]

Igazad lett mégis. Most néztem rá a régi lapra, és két tüske el van görbülve rajta egy kicsit. Nem tudom, hogy ez érdemben befolyásolja e, de majd visszarakom őket a helyükre, aztán meglátjuk. Így is úgy is eladom, mert nincsenek meg a lane-ek a hálókártyához, de azért jobb lenne teljes áron, mint hibásként. Ma jött meg a másik lap, mindjárt kipróbálom, hogy az hogy szuperál, meg akkor már végre a processzort is, hogy az is hibás e. Még bizakodó vagyok, hogy az talán rendben lesz.

[ Szerkesztve ]

Buliban hasznos! =]

Na úgy alakult, hogy küzdök a FreeBSD-vel. Az új alaplapnál nem igazán akarja felismerni az alaplapi hálókártyát, a másik gépen meg egy update után elment az asztali környezet, úgyhogy nem tudom azt csinálni, hogy a szerver gépen böngészek, hogy hogyan tákoljam meg az asztalit. Majd beállítom a sorba a laptopomat, úgyis ritkán használom, de ma nincs kedvem kínlódni ezzel, úgyhogy most egy darabig nem lesz wrk.

Mivel az iperf3 fent volt alapból mindkét gépen, ezért azzal tudtam mérni mielőtt elszabadult a pokol, egész szépek most az eredmények.

root@pc1:/usr/home/inf3rno # iperf3 -c 192.168.13.14 -p 5002
Connecting to host 192.168.13.14, port 5002
[ 5] local 192.168.13.13 port 11231 connected to 192.168.13.14 port 5002
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 943 MBytes 7.91 Gbits/sec 2 1.71 MBytes
[ 5] 1.00-2.00 sec 1.08 GBytes 9.25 Gbits/sec 0 1.71 MBytes
[ 5] 2.00-3.00 sec 1.08 GBytes 9.24 Gbits/sec 0 1.71 MBytes
[ 5] 3.00-4.00 sec 1.07 GBytes 9.23 Gbits/sec 0 1.72 MBytes
[ 5] 4.00-5.00 sec 1.08 GBytes 9.24 Gbits/sec 0 1.72 MBytes
[ 5] 5.00-6.00 sec 1.08 GBytes 9.24 Gbits/sec 0 1.73 MBytes
[ 5] 6.00-7.00 sec 1.08 GBytes 9.24 Gbits/sec 0 1.73 MBytes
[ 5] 7.00-8.00 sec 1.08 GBytes 9.23 Gbits/sec 0 1.73 MBytes
[ 5] 8.00-9.00 sec 1.08 GBytes 9.24 Gbits/sec 0 1.74 MBytes
[ 5] 9.00-10.00 sec 1.07 GBytes 9.23 Gbits/sec 0 1.74 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 10.6 GBytes 9.10 Gbits/sec 2 sender
[ 5] 0.00-10.20 sec 10.6 GBytes 8.93 Gbits/sec receiver

iperf Done.
root@pc1:/usr/home/inf3rno # iperf3 -c 192.168.13.14 -p 5002 -R
Connecting to host 192.168.13.14, port 5002
Reverse mode, remote host 192.168.13.14 is sending
[ 5] local 192.168.13.13 port 12563 connected to 192.168.13.14 port 5002
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 946 MBytes 7.93 Gbits/sec
[ 5] 1.00-2.00 sec 1.09 GBytes 9.40 Gbits/sec
[ 5] 2.00-3.00 sec 1.09 GBytes 9.40 Gbits/sec
[ 5] 3.00-4.00 sec 1.09 GBytes 9.40 Gbits/sec
[ 5] 4.00-5.00 sec 1.09 GBytes 9.40 Gbits/sec
[ 5] 5.00-6.00 sec 1.09 GBytes 9.40 Gbits/sec
[ 5] 6.00-7.00 sec 1.09 GBytes 9.40 Gbits/sec
[ 5] 7.00-8.00 sec 1.09 GBytes 9.40 Gbits/sec
[ 5] 8.00-9.00 sec 1.09 GBytes 9.40 Gbits/sec
[ 5] 9.00-10.00 sec 1.09 GBytes 9.40 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.01 sec 10.8 GBytes 9.24 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 10.8 GBytes 9.25 Gbits/sec receiver

iperf Done.

Szóval a PC-ről a szerverre 9.24 Gbps, a szerverről a PC-re meg 9.40 Gbps. Csináltam rá UDP-t is, de 9.55Gbps-nél sosem mértem többet.

Mértem FTP-vel másolást még ez mellé, az 274 MB/s (2.192 Gbps) lett a szerverről a PC-re, és 343 MB/s (2.744 Gbps) lett a PC-ről a szerverre. Az előzőek 240 és 340 voltak, úgyhogy valamit javult a feltöltés. Nem néztem meg, hogy a CPU használat hogy áll közben, lehet, hogy az SSD-k nem elég gyorsak, lehet, hogy a CPU fogy el, az is lehet, hogy a ZFS fájlrenszer miatt lassú, vagy esetleg az FTP nem erre való, passz. Egyelőre nem lesz NVM ezeken a gépeken, és a mostani SSD-k is elég jók.

A szerveren egy Micron-ra írtam, annak megvannak a crystaldiskmark eredményei:

Az asztali gépen egy Samsung 860 EVO 250GB, amin mértem, az elvileg 400MB/s felett tud írni. [link] Szerintem még többet is ki lehet hozni valamivel ezekből az SSD-kből. A CPU-ból meg pláne, mert most minden alapbeállításon vagy az alatt van. Az asztalit majd OC-zem, abból olyan 1.5x ekkora erőt ki lehet hozni.

Szerintem én egyelőre most jegelem ezt a sztorit, mert a 300MB/s is már egész jó, és a kártyák is láthatóan rendben vannak. Később majd visszatérek rá, hátha feljebb tudom hozni. Most van bőven dolgom az új alaplap kapcsán, a legnagyobb gond vele, hogy a Sabaj D3-at ledobja 5 percenként USB-ről. Meg újra akarom tenni a rendszert 4 gépen, ami szintén nem 5 perc lesz...

[ Szerkesztve ]

Buliban hasznos! =]

Jaja.

Buliban hasznos! =]

Nekem is ez a bajom. Beleraknak 1db 2.5Gbites portot, és ettől oda meg vissza kellene lennünk...

Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

Nem is ertem,ki fogja ezt megvenni.
Ha mar Gigabit feletti a wan linkem,akkor nyilvan nem szeretnem az osszes gepet a lanon gigabitre korlatozni.
Ok, lehet egyszerre ket geprol is gigabiten torrentezni (ha a proci birja a sokszalas natolast), de itt kb. el is fogytak az elonyei.

[ Szerkesztve ]

Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben

Ethernet header 14 byte, IP header 20 byte. --> 34 byte minden frame-en.
1500 byte --> ~2%
9000 byte --> ~0,3%
6 header helyett csak 5-öt kell kiszámolni, igaz 6x akkora csomagra...
Lehet vele nyerni, de azért hibahatáron belül marad

Hát amennyire én értem, egyik oldalról gyorsítja a kevesebb header, másik oldalról meg visszafogja, hogy néhány csomagot újra kell küldeni. A gyakorlat szempontjából nem tudom mennyi jelentősége lenne. Az iperf-nél is volt néhány retransmit, az szerintem el is vinné azt a kis extrát, amit ezzel nyerek.

Legtöbbször valszeg valami RDF formátumot fogok küldeni, pl JSON-LD, ezek szövegesek, esetleg base64 encoded lehet belefűzve bináris adat is, de jó eséllyel azt inkább külön küldöm. Majd lemérem, hogy hány bájt egy ilyen, aztán lehet, hogy érdemes lesz növelni, ha az 1500-ba nem fér bele egy átlagos. Amúgy ez hogy működik, lehet eltérő a helyi hálón a routerhez képest, aztán majd ha kimegy a netre, akkor feldarabolja, esetleg a bejövőket buffereli, amíg egy csomagra elég bejött?

Buliban hasznos! =]

nem savszel limiten segithet, hanem amikor a csomag/s tul sok az adott applikacionak