- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
ph A Kereskedelmi Minisztérium egyelőre csak felméri a helyzetet, egyelőre nem látni, hogy tudnak-e bármit is tenni.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Már tudjuk, hogy mikor jön az idei Xbox Games Showcase
gp A showt egy külön Direct előadás követi, ami szinte biztosan az idei Call of Duty lelepelzése lesz.
-
PROHARDVER!
Haladó szintű hálózati témák topikja
Új hozzászólás Aktív témák
-
#25954560
törölt tag
sziasztok,
adott egy halozat ~30 hosttal (win7 +winxp), ket app szerverrel, 3 db 24port-os switch-csel. hurok nincs.
mitol fordulhat az elo h egyszercsak az arp request-ek elkezdenek burst-osodni? vegul mar 5-10sec-enkent jon hatalmas mennyisegu, pingek valaszideje leesik 1-2 sec fole, nehany gep nem is latja a kiszolgalokat. gyakorlatilag ARP DoS szeruseg tortenik. viszont ugy nez ki h ugyanaz a mennyisegu arp azelott is megvan a haloban, csak nem burst-ben jon es olyankor nincs is problema.
koszi,
&rew -
#25954560
törölt tag
saccoltam
wireshark-kal neztem a halozati forgalmat es egy szazadmasodpercen belul jott ~40 arp request. ha mentek folyamatosan a pingek a szerver fele, akkor az arp-ok megjelenese utan kozvetlenul ugrott fel a valaszido nagyra, vagy akar volt h ki is maradt.
a gaz az, hogy (mar) fix ip-sek a gepek egy ido ota.
en is ertetlenul ulok a problema elott.mod: amit meg nem neztem meg, hogy az arp request-re megkapja-e a kerdezo gep a valaszt. vagy nem kapja meg, vagy valamiert eldobja, mert tipikusan csak par geptol jon, holott az arp cache-ben bent kene maradjon az elso valasz utan.
[ Szerkesztve ]
-
#25954560
törölt tag
válasz kraftxld #2523 üzenetére
tuti nincs, ezt es a hurkot ellenoriztem eloszor.
dhcp volt regebben, aztan valami varazslatos hiba elharitasara a rendszergazda a fix ip-ket valasztotta. egyebkent nincs is ezzel baj, a halo nagyon ritkan valtozik, en is ezt tettem volna. letezik hatranya a fix ip-nek?tipikusan az a halozat, amit mindig peccselgettek, illetve 'ideiglenes' megoldasokkal foltoztak. nincs ember, aki ismeri az egeszet, en raadasul most latom eloszor. illetve masodszor, hosszabb-rovidebb ejszakai hegesztesek kapcsan.
van pl rajta egy dns szerver (?), amin bsd fut es senki nem tud ra belepni de allitolag kell, bar en a netbios-t es a dns-t egyszerre nem tartanam fent, de nem ertek a vindozos dolgokhoz. -
#25954560
törölt tag
válasz bambano #2526 üzenetére
jah, csereltunk kartyat. kivancsi vagyok h mi lesz, nem tudjuk eloidezni a hibat. elkolbaszol a halo akar 2-3 orat is, aztan egyszercsak. egyebkent fura nekem ez a 0-s checksum... a kartya beallitasai kozott van vmi tcp meg udp meg ip header checksum offload, na az eddig enabled volt. asszem kikapcsolom, nagyon gyanus.
vagy pedig volt rendesen checksum csak mivel a szerveren futott a wireshark es a kartya szamolja es teszi hozza hw-bol a checksum-ot, ezert a wireshark nem tudhatott rola
[ Szerkesztve ]
-
#25954560
törölt tag
válasz kraftxld #2530 üzenetére
de nemtom eloidezni a hibat csak nagysokara.
ha holnap nem lesz tifuszos a halo, akkor rafogom h a halokartya-csere megoldotta (es az egyik switch hub uzemmodban ment, azt is lecsereltuk). ha viszont kohog, akkor jon az egyesevel feldugdossuk technika.
mar igy is egy csomo madzagot sporoltunk amirol nem tudtuk h mi, nem dugtuk vissza. es ma megsem panaszkodott senki h nem megy valamije tanulsagos. valszeg nekiesunk reszletesen felterkepezni a halot es egyszerusiteni, ha lehet. -
#25954560
törölt tag
sziasztok (hello inf3rno )!
otletekert jovok hozzatok, hatha.
madzagon szembedugtam egymassal ket eros linuxos gepet, a ketto kozott 100G kapcsolat. UDP-vel at tudok kergetni kb 82Gbps-t (tobb iperf3, pinelve, stb), de TCP-vel nem jutok 60Gbps fole (wrk az egyik oldalon es egy tuningolt apache a masikon, 64k-s html-t huz le) es ugy latszik, hogy nem a CPU a szuk keresztmetszet.mindket gepen probaltam tuningolni a TCP beallitasokat, tipikusan nagy savszelhez es nem kis keslelteteshez, de most megallt a tudomany
a kerdes: tudja-e valaki, hogy hogyan lehet kiszamolni, hogy adott TCP stack-nek bizonyos beallitasok mellett mennyi az elmeleti savszelessege?
a halokartyak nem valtanak poll modba, vegig megszakitassal mennek. gro-t kikapcsoltam, mert igy gyorsabb.
barmi otlet erdekel.
koszi! -
#25954560
törölt tag
esack van, ablakmeret felmegy szepen oriasira. wrmem es rdmem nagyra van allitva. capture nem igazan megy ekkora savszelnel, mar befolyasolja az atvitel sebesseget es oriasi lenne a file, talan ha az atvitel kozepen probalnek kicsit, az mukodhet. reorder nincs, retransmit viszont van keves. lehet agresszivebre kene allitani az ablakmeret-noveles sebesseget. a halokartyaknal az rx es tx hwq meret is 4k-ra van veve.
inf3rno:
koszi, nezegettem mar en is tobbfele leirast. es a kb 60Gbps az nem a hasznos, hanem az abszolut savszel. apache valami hasonlo alapjan van feltuningolva[ Szerkesztve ]
-
#25954560
törölt tag
válasz bambano #10844 üzenetére
koszonom, ezeket mar megneztem megszakitasok szepen el vannak osztva es nagyobb (1M) fajllal sem no az atvitel sebessege.
cubic helyett probaltam mar a htcp-t, de egymassal szembekotve nem igazan kene egyaltalan h bejojjon a congestion control. a bbr-t azert megnezem, korabban hasznaltam azt is, de a tuzfal (amikor kozottuk van), gyakorlatilag tonkreteszi, mert rengeteget bufferel (L7 threat protection)crok:
jogos, a teszthez a header eleg. tukrozest en is csinaltam mar igy pl intel 82599-en. most viszont az ice az csak 1x100G, nincs hova tukrozni (bar lehet megnezem megint mit alkot 2x100G-re konfigolva). a tcp-vel kapcsolatos iromanyodat pedig meg emesztenem kell en altalaban a masik vegen allok a halokartyanak, userland packet processing-ben utazom, a protokoll sztekkek mar altalaban felhasznaloi retegek a szamomra. de jo otlet megnezni pl a 0win-t, koszi. gondolom a retransmittol meg kene szabadulni, az nyilvan elvesztett csomagot jelent (vagy tul keson megvalaszoltat)[ Szerkesztve ]
-
-
#25954560
törölt tag
válasz gergogazd #10893 üzenetére
sajnalom, linuxrol jovok
nem szamit h telefonra osztod tovabb a netet. ugy ertettem, hogy amikor tovabb van osztva a net masik gepnek, akkor a telefon csinal mindent, a windows csak nat-ol, forgatja az IP cimeket.egyebkent a laptop tetszoleges bongeszovel, a legujabbakkal sem muxik minden oldal fele?
nem lehet h valami tuzfal szabaly vagy bongeszo kiegeszito miatt nem mukodik, ugye? -
#25954560
törölt tag
válasz Dißnäëß #10912 üzenetére
roviden: gozom sincs melyikre gondolt a felhos kollega, ezert:
a halozatoknal leggyakrabban ez a harom kulonbozo idore vonatkozo parameter van:
- RTT: round trip time, ahogy te is irod: elkuldesz egyik oldalon valamit es a teljes ideje, mire a valasz visszaer
- delay: a halozat kesleltetese, az egyik eszkoz elhagyasatol a masik eszkozig erkezes ideje
- latency: a halozati eszkozok altal hozzaadott kesleltetes (tehat pl minel tobb eszkozon mesz keresztul, azok konfiguraciojatol es kepessegeitol fuggoen annal tovabb for tartani a csomag utja)a ping RTT-t mer (kb), ahogy irod is. az echo request elkuldesetol az echo reply megerkezeseig eltelt idot (ha nagyon haklisak akarunk lenni, akkor az ICMP protokollal elerheto RTT-t, adott prioritas mellett, mindketto szamithat)
eleg megnezni a printoutjat, abban is rtt-t ir--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 2.533/2.673/2.792/0.106 msa latency vs delay erdekes megkozelites, ugy latszik a latency-t neha a delay megfelelojekent hasznaljak, mashol is hallottam mar. magyarul mindig csak kesleltetesnek hallom.
mod: na akkor most mar lattam a valaszido megfelelojekent israadasul nem mondhatjuk, hogy az RTT-t megfelezve megkapjuk mindig az egyik iranyba szukseges idot, mert halozattol fuggoen mehet masfele a keres es a valasz (kozvetlen drotos osszekottetesnel persze nem).
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Milyen TV-t vegyek?
- Honda topik
- No Voice in the Galaxy
- gban: Ingyen kellene, de tegnapra
- KERÉKPÁR / BRINGA / ALKATRÉSZ beárazás
- Call of Duty: Modern Warfare III (2023)
- VR topik (Oculus Rift, stb.)
- Poco X6 Pro - ötös alá
- Kerékpárosok, bringások ide!
- Szevam: Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- További aktív témák...