Van egy dedikált GSM/GPRS APN. Két C osztályú szegmenst kaptunk (azaz 510 eszköz lóghat rajta maximum). A GSM szolgáltatóhoz egy bérelt, kábeles vonal megy, ez bedől egy CISCO routerbe, ami mindent etherneten egy IP címre routol, ami az egyik "szerveren" található.
Na már most, a gondom az, hogy lövésem sincs mekkora a sávszélességem!
Jobb ötlet híján levettem az ethernet interfész statisztikai adatait:
$netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 45564329 0 0 0 45458706 0 0 0 BMRU
...
És elővettem az uptime -ot:
14:16:18 up 134 days, 21:54, 1 user, load average: 0.02, 0.01, 0.00
(sokat malmozik ez a jószág :)
Úgy gondolom, hogy az interfész statisztika a teljes uptime -ra vonatkozik, ekkor így kalkuláltam:
Rx 45.564.329
Tx 45.458.706
91.023.035 x 1500 = 1,365345 e+11 [bájt]
134 x 86.400 = 11.577.600
14 x 3.600 = 50.400
16 x 60 = 960
11.628.960 [sec]
1,365345 e+11 / 11.628.960 = 11.740,908 [bájt/sec] ~ ck. 120 Kbit/sec
Ebből, a szokásos lehetőségeket figyelembe véve, 128 Kbit/sec lehet a csatorna átvitel.
Szerintetek ez helytálló? Jól okoskodom?
szerk:
Viszont a $netstat -ie bájtokban is megadja az eddigieket :)
Rx 1.169.844.796
Tx 2.351.719.904
3,521564 e10+9
135 x 86.400 = 11.664.000
16 x 3.600 = 57.600
51 x 60 = 3.060
11.724.660
vagyis
300,35532 [bájt/sec] azaz, ck. 3 Kbit/sec
Azt hiszem, ha ez így helytálló, akkor nincs olyan lassú vonal ami ezt ne bírná, akár többször! :)
- 1674 megtekintés
Hozzászólások
Nem lényeges, de csak 508 IP címet oszthatsz ki. 254 állomás hálózatonként (2^8 -2)
127.0.0.1 SWEET 127.0.0.1
- A hozzászóláshoz be kell jelentkezni
Jogos :) 254 + 254 még mindig 508 - szerencsére elég messze vagyunk attól, hogy ezt kihasználjuk.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Ok :)
Nem kötekedni akartam, csak végre lett valami, amire írhatok :D
127.0.0.1 SWEET 127.0.0.1
- A hozzászóláshoz be kell jelentkezni
Már ha két *különálló* C-t kaptak.
- A hozzászóláshoz be kell jelentkezni
Nem vettem annak! Volt olyanban is részem az nem így fest :)
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
És ha a két /24 valójában egy darab /23?
- A hozzászóláshoz be kell jelentkezni
"91.023.035 x 1500"
Nem biztos, hogy az osszes paket 1500 byte-os.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Sőt, biztos hogy nem! Akkor ez így megint nem mond semmit :(
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
A válasz az, hogy "az attól függ".
A sávszélességed nem lesz 'dedikált', mert mindig függ attól, hogy az adott TE éppen hol jár. -> és a TE-k összessége mennyit forgalmaz adott időben.
Szerintem elkérheted a szolgáltatótól az APN statisztikát.
Dedikált APN, két C-nyi subnet, és bérelt vonal mellett ez a minimum, amit kiadhat ennyi pénzért az operátor.
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy en nem ertem a kerdest, de miert nem tamadod meg a routers SNMP+MRTG parossal? Ez elvileg kellene, hogy tudjon adni egy statisztikat, ami neked kell...
- A hozzászóláshoz be kell jelentkezni
Lehet hogy félreértem, de az iptraf parancs nem lenne jó neked megmérni a pontos sebességedet?
- A hozzászóláshoz be kell jelentkezni
Destruktív eszközökkel nem méricskélhetek ebben a hálózatban! Pillanatnyilag az is elég, ha tudom hol tartunk és mennyit lehet erre még ráterhelni. A 300 Kbit/sec biztos nem egy határérték.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
...es ezt most mire irtad? :) Melyik javaslat volt destruktiv?
- A hozzászóláshoz be kell jelentkezni
Tipp: az iptraf tud erőforrást kajálni, igaz, nekem csak kitömött gigás interfésznél volt vele ilyen tapasztalatom...
- A hozzászóláshoz be kell jelentkezni
Szinte bármi, ami a normál kommunikációba beleszól :(
Igaz, ha megnézed az uptime adatokat, a CPU malmozik ...
Egyszerű lenne megnézni a sávszélesség adatot, akár egy szimpla ping flood -al de ez szétdöntené a hálót jó néhány percre ...
Azt hiszem ez az egyszerű becslés elég jó nekem amire kellett hiszen az átlagos terhelés nem éri el a 9600 baud -nak megfelelő mozgást ...
A hálózat még egyértelműen tovább terhelhető, akadályt csak a csúcs terhelések jelenthetnek, amiről sajnos nincs adatom ...
Esetleg, ha valami halál primitív módon ki nem nyerem az átvitt bájtok számát, mondjuk a /proc vagy a /sys fájlrendszerből ... utána kell néznem. Ha ezt az adatot naplóznám képet kaphatok a csúcsokról és nem kell komolyan beletúrni a rendszerbe.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
"300,35532 [bájt/sec] azaz, ck. 3 Kbit/sec"
Nem 0,3Kb?
- A hozzászóláshoz be kell jelentkezni
300,35532 bájt/s * 8 bit = 2402,84 bit/s -> 2,3465 kbit/s
- A hozzászóláshoz be kell jelentkezni
Nagyon durva kalkuláció, de úgy számolok, hogy egy byte (azaz 8 bit) átviteléhez kb. 10 bitet kell fizikailag átvinni. Való igaz, hogy ezt a primitív számítást, az aszinkron soros kommunikációból hoztam (1+8+1 azaz 10 bit ha nincs paritás bit). Persze itt szinkron kommunikáció zajlik, viszont ha belegondolsz a szinkron csomagok fizikai összetételébe, akkor ott is van jócskán "overhead", viszont ott egy csomagban jóval több adat megy ezzel a burkolattal. Sok gond van ezzel a becsléssel, pl. a csomaghosszok változnak, viszont az "overhead" nem ...
Minden estre úgy gondolom ez elég jó alap becslésnek.
* Én egy indián vagyok. Minden indián hazudik
- A hozzászóláshoz be kell jelentkezni