welke route volgt netwerkverkeer

[timberleek]

hallo

Misschien een rare vraag, maar welk pad volgt netwerkverkeer.

ik heb nu bijvoorbeeld een homeserver (freenas). die heeft een Gbit nic. mijn desktop ook.
de 2 kasten staan op een paar meter afstand beide aangesloten op een tp-link sg1008 switch. tussen beide krijg ik echter maar een downloadsnelheid van ca 15MB/s max na stabilisatie.

van de switch gaat er een kabel naar een wr1043nd router als access point. en van daaruit een kabel 2 verdiepingen naar beneden naar de eigenlijke router. ook een wr1043nd.

ik bedacht me ineens dat het verkeer misschien eerst helemaal naar beneden gaat. daar wordt het 'gerout' en dan komt het weer terug.

maar dat zou ook zomaar onzin kunnen zijn.

daar hebben jullie vast meer verstand van...

[Tsurany]

Dat klopt, dat is niet correct. Een switch houd in een tabel bij welke IP adressen aan welk MAC adres vast zit en kan zo dus het verkeer doorsturen naar de juiste poort. Het gaat dus gewoon van homeserver via je switch direct naar je desktop toe.

[allure]

De data gaat op de eerste switch van poort naar poort. De data komt niet bij de router aan...

Als je ditzelfde probeerd via een pc die verbonden is middels Wifi, dan gaat de data WEL via de router omdat de poorten van de router een ingebouwde switch is.

[Voor 46% gewijzigd door allure op 03-06-2011 22:08]

[Gomez12]

Wat bedoel je met "na stabilisatie"?

Want behalve als je je switch extreem raar hebt ingesteld gaat het gewoon niet verder dan de switch.

[timberleek]

als ik ga kopieren (vanuit samba) naar mijn desktop dan begint hij vaak met hele hoge getallen. en dat zakt dan terug naar 10-15MB/s

aan die switch is volgens mij niks in te stellen.

de reden van de vraag is vooral omdat ik aan het zoeken ben naar een zondebok voor de 'lage' snelheid

[Voor 22% gewijzigd door timberleek op 03-06-2011 22:08]

[Gomez12]

Trekt je hardware van je freenas het wel? Of is dat gewoon een oud beestje wat niet meer trekt...

Simpelste methode is gewoon switch loskoppelen van router en dan nog eens proberen, daarna ook switch ertussenuit.

[ZpAz]

Tsurany schreef op vrijdag 03 juni 2011 @ 22:04:
Dat klopt, dat is niet correct. Een switch houd in een tabel bij welke IP adressen aan welk MAC adres vast zit en kan zo dus het verkeer doorsturen naar de juiste poort. Het gaat dus gewoon van homeserver via je switch direct naar je desktop toe.

Een switch heeft toch geen weet van IP-adressen en routeert gewoon op basis van Mac adres? (Wat ook mee gestuurd wordt binnen het netwerk met pakketjes).

[Tsurany]

Dat zou ik niet weten, ik weet grofweg hoe het in elkaar zit en hoe je bijvoorbeeld ARP poisoning kan toepassen. De exacte details kan ik je niet vertellen.

Ik zou inderdaad de switch er tussenuit trekken en het dan proberen, grote kans dat je FreeNAS systeem niet helemaal lekker werkt.

[Voor 30% gewijzigd door Tsurany op 03-06-2011 22:20]

[timberleek]

het is een foxconn met e2160 dual core
http://www.foxconnchannel...view.aspx?ID=en-us0000227

ik maakte alleen een fout vanmiddag.
ik dacht dat hij 10/100 had dus ik heb er een Gbit pci kaart in gekocht. daarmee is het nog dramatischer. mogelijk dat hij niet goed herkend wordt. maar toen las ik nogmaals. bleek er wel een gbit nic in te zitten

[yay]

Ik heb eerst wat vragen ;-)
1. Wat voor hardware heb je staan? (Zoals al gezegd werd even weten of je hardware eea aan kan)
2. Zijn je kabels wel oké? Een defecte kabel kan zorgen dat je wel data over kan sturen maar dat hij op 100mbps werkt.
3. Zegt ifconfig op je nas dat je 1000mbps draait?

[Voor 1% gewijzigd door yay op 03-06-2011 22:25. Reden: Hardware vraag al beantwoordt]

[frickY]

Houd ook rekening met de configuratie van Samba zelf, die een hoop invloed op de snelheid kan hebben.

[Tsurany]

Niet alleen een defecte kabel, als het slechts 4 aders heeft houd het ook al op.

[timberleek]

ifconfig in freenas geeft me dit:

code:

$ ifconfig
re0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
    ether 00:11:6b:98:e0:98
    media: Ethernet autoselect (1000baseTX <full-duplex>)
    status: active
sk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=b<RXCSUM,TXCSUM,VLAN_MTU>
    ether 00:15:58:96:43:2c
    inet 192.168.1.250 netmask 0xffffff00 broadcast 192.168.1.255
    media: Ethernet autoselect (1000baseTX <full-duplex,flag0,flag1>)
    status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
    inet6 ::1 prefixlen 128 
    inet 127.0.0.1 netmask 0xff000000

hij herkent het duidelijk wel als gbit

en cifs instellingen zijn:

[Voor 6% gewijzigd door timberleek op 03-06-2011 22:30]

[yay]

Klopt, gbit (Adapter en kabel) aan de NAS-kant goed.

Nu de andere kant: wat is de client?

[timberleek]

de andere kant is een hp pavilion elite m9180 desktop.
amd phenom 9500

en (net geplaatst, maar mocht geen baat hebben) een level one gnc-0105t pci gbit kaart

ipconfig geeft mij:

[Voor 24% gewijzigd door timberleek op 03-06-2011 22:37]

[Gomez12]

Waarom heb je je sendbuffer size en je receive buffersize aangepast? Zal vast geen grote invloed hebben hierop, maar bij troubleshooting is het wel zo handig om alles te weten...

[timberleek]

ik zou het eigenlijk niet weten. het is al even geleden.

maar toen heb ik volgens mij iets gelezen over hogere buffers-> hogere snelheid
maar ik zal het eens terugzetten

met de originele 64240k blijft het hetzelfde verhaal.
ik zal ook de asynchronous io en die tuning switch eens proberen zoals freenas zelf aangeeft

met async spul en tuning aan is het ook 10-15MB

overigens geeft de switch van alle kabels aan dat het Gbit is

[Voor 45% gewijzigd door timberleek op 03-06-2011 22:43]

[Kabouterplop01]

Alleen de allereerste pakketjes gaan eerst naar je router, deze houdt de ARP tabel bij.
ARP is de koppeling van ip naar mac-address. Als de router eenmaal "weet" welk mac address er bij het ip hoort stuurt deze het door naar de switch dan heb je een laag 3 verbinding (dus van ip naar ip adres), daarna zla het op basis van de mac adressen gaan en blijft het verkeer alleen op de switch. (tot de arp cache een timeout krijgt en dan krijg je weer een arp request)
Als je test met een live CD van Ubuntu op je PC, wat krijg je dan voor snelheden?

Overigens die buffers groter zetten is niet zo heel gek. echter je ontvangst en receive buffers moet je aanpassen.
immers moet je de acks van de pakketjes terugsturen. met grotere ontvangst krijg je beter performance, maar wel in verhouding met je transmit buffers, zodat je sliding window size groter wordt. Je wil zo snelmogelijk zo veel mogelijk verkeer binnenhalen, maar ook versturen.
@ Hieronder:
@Sendy: Staat er in mijn post dan dat die host niet zelf antwoordt? ARP... who has.... tell ....
@Cyber: Deze kerel heeft een default gateway en dus een L3 gedeelte: Kun je het even uitleggen? (Met router graag) We snappen allemaal hoe het met laag 2 zit...dan houden de PC's de arp cache zelf bij.(Ja beetje summier, bij een L3 netwerk ook)

[Voor 15% gewijzigd door Kabouterplop01 op 05-06-2011 08:51]

[Sendy]

Kabouterplop01 schreef op vrijdag 03 juni 2011 @ 22:50:
Alleen de allereerste pakketjes gaan eerst naar je router, deze houdt de ARP tabel bij.
ARP is de koppeling van ip naar mac-address. Als de router eenmaal "weet" welk mac address er bij het ip hoort stuurt deze het door naar de switch dan heb je een laag 3 verbinding (dus van ip naar ip adres), daarna zla het op basis van de mac adressen gaan en blijft het verkeer alleen op de switch. (tot de arp cache een timeout krijgt en dan krijg je weer een arp request)

Onzin. Het eerste pakketje dat de afzender stuurt is wel een ARP-request, maar de geadresserde machine zal zelf antwoorden. Hierna weet de afzender het mac-adres en kan er "echt" IP-verkeer verstuurd worden. Een switch heeft helemaal geen weet van IP en houdt alleen bij welke mac-adressen aan welke poort hangen.

edit:
Te laat, Cyber

[CyBeR]

Kabouterplop01 schreef op vrijdag 03 juni 2011 @ 22:50:
Alleen de allereerste pakketjes gaan eerst naar je router, deze houdt de ARP tabel bij.
ARP is de koppeling van ip naar mac-address. Als de router eenmaal "weet" welk mac address er bij het ip hoort stuurt deze het door naar de switch dan heb je een laag 3 verbinding (dus van ip naar ip adres), daarna zla het op basis van de mac adressen gaan en blijft het verkeer alleen op de switch. (tot de arp cache een timeout krijgt en dan krijg je weer een arp request)

Sorry, maar daar klopt dus werkelijk geen drol van. Binnen een L2 ethernet broadcast domein loopt communicatie nooit via de router. Die houdt ook niet "de" ARP-tabel bij, die houdt er, net als elke andere ethernet host één bij.

Sendy schreef op vrijdag 03 juni 2011 @ 23:14:
[...]

edit:
Te laat, Cyber

Bleh, ik zat op m'n telefoon in de tram ja, dat gaat langzamer

[Voor 12% gewijzigd door CyBeR op 04-06-2011 00:17]

[Gomez12]

Sendy schreef op vrijdag 03 juni 2011 @ 23:14:
[...]

Onzin. Het eerste pakketje dat de afzender stuurt is wel een ARP-request, maar de geadresserde machine zal zelf antwoorden. Hierna weet de afzender het mac-adres en kan er "echt" IP-verkeer verstuurd worden. Een switch heeft helemaal geen weet van IP en houdt alleen bij welke mac-adressen aan welke poort hangen.

edit:
Te laat, Cyber

Theoretisch kan je via vlan's / routers nog wel een situatie creeeren dat geadresseerde machine niet kan antwoorden ook al hangt hij aan dezelfde switch. Waardoor je theoretisch (mits je 1e router ook weer vlan's etc ingesteld heeft) wel pas bij de router beneden pas de route krijgt.

Maar dan heb je het of bewust ingesteld, of je omgeving zwaar verneukt...

Het is dus niet 100% onzin, enkel 99% en totaal niet van toepassing op deze situatie...

[timberleek]

bij het kopieren van de ene hd naar de andere (beiden binnen de nas, maar kopieren via mijn desktop) loopt te snelheid naar ca 7 - 8MB/s

morgen eens proberen via mijn laptop

[Gomez12]

timberleek schreef op vrijdag 03 juni 2011 @ 23:54:
bij het kopieren van de ene hd naar de andere (beiden binnen de nas, maar kopieren via mijn desktop) loopt te snelheid naar ca 7 - 8MB/s

morgen eens proberen via mijn laptop

Hoe kopieer je het dan? Zit je via windows explorer de bestanden te kopieren van de ene nas-map naar de andere?
Want dan gaat er echt iets zwaar fout, of je netwerk is half-duplex of je nas kan gewoon niet hoger dan 15mb/s op schijf doen...

Als het aan je netwerk zou liggen dan zou je alsnog 15mb/s halen als het gewoon full-duplex is.

[Fish]

Ga eens met iperf testen om zoveel mogelijk pc hardware uit te sluiten

ben je bang dat het geroute wordt, doe een tracert

[Voor 29% gewijzigd door Fish op 04-06-2011 00:11]

[timberleek]

ik kopieer inderdaad via win explorer.

het mobo heeft sataII volgens de site.

de schijven zijn een 500gb WD caviar:
WDC WD5000AAKS-65YGA0

en een 750gb seagate barracuda:
ST3750330AS

iperf geeft :
interval: 0.0-10.0 sec
transfer 320MBytes
bandwith 268Mbits/sec (iperf server zegt 269)

o wacht. mijn laptop staat nog op wireless.

met kabeltje is het:
0.0-10.0 sec
326MBytes
273 Mbits/sec (weer eentje meer bij de server --> 274Mbits/s)

dit is gedaan tussen mijn laptop en desktop
beide met een kabeltje aan de switch
ik zal het morgen nog eens proberen, maar dan met een andere kabel aan de desktop.
aan alles zit nieuwe cat6 bekableling. maar aan de desktop nog niet zie ik nu.

ik zal nog even snel proberen te verplaatsen tussen laptop en nas. dan geef ik er de brui aan voor vandaag

edit:
nas hd1 --> nas hd2 via windows verkenner op laptop gaat met ca 15-16MBit.
toch al 2 keer zo snel...

[Voor 6% gewijzigd door timberleek op 04-06-2011 00:33]

[Fish]

Moet je eens grotere pakketjes 64k ofzo proberen dan wordt het nog hoger zelfs

Het gaat toch niet van/naar een usb2 schijf ?

[Voor 23% gewijzigd door Fish op 04-06-2011 00:36]

[timberleek]

ik zie dat de snelheid al weer een stuk is terug gevallen naar ca 8-9MB
om vervolgens weer op te lopen naar 11

met tcp window size 16k --> 415MBit/s
met tcp window size 64k --> 707MBit/s

[Eagle Creek]

ZpAz schreef op vrijdag 03 juni 2011 @ 22:16:
[...]


Een switch heeft toch geen weet van IP-adressen en routeert gewoon op basis van Mac adres? (Wat ook mee gestuurd wordt binnen het netwerk met pakketjes).

Een switch zit op laag 2: Mac dus.
Een router zit op laag 3: IP dus.

Er bestaan multi-layer switches die met IP werken, maar die zie je in de thuisomgeving niet.

(FYI)

@Timberleek: staan Jumbo-frames soms aan? Toen ik dit uitschakelde tussen server en NAS verdrievoudigde mijn snelheid. Dit zou uiteraard niet moeten, maar zo was het wel.

[Voor 16% gewijzigd door Eagle Creek op 06-06-2011 13:29]

[timberleek]

Ik ben iets verder.

vermoedelijk heeft het wat te maken met de transmission client in freenas.
telkens als ik spullen verplaats kopieer ik het van de transmission directory naar de nieuwe schijf.
transmission is dan nog aan het seeden. na het kopieren zeg ik in transmission 'trash data and remove from list'.

de reden hiervan is omdat ik hem niet kan verwijderen uit transmission en dan kan knippen plakken doordat transmission dit nog wel tegenhoudt.


maar nu had ik een berg data die nooit in transmission heeft gestaan (zelf naar die map gekopieerd) nu ik die verplaats naar de andere schijf krijg ik wel 15-20MB/s bij het overkopieren via windows verkenner.

daar zit dus een clue. bij data die wel in transmission staat is het de helft.


@eagle creek
waar staat dit?

is dat 'enable large read/write'?
"Use the new 64k streaming read and write varient SMB requests introduced with Windows 2000."
die staat aan.

[SMSfreakie]

k heb hier een singlecore 1640LE met 1GB staan met FreeBSD en samba 3.3.8..(waarop FreeNAS gebaseerd is.. ) zonder byzondere instellingen.. en dat trekt gewoon tegen de 900MBIT/s zowel read als write

k wil mn smb.conf wel dumpen maar daar staat niks boeiends in afaik..

enige wat ik nog kan bedenken is dat je filesystem evt roet in je snelheid strooit

[Voor 19% gewijzigd door SMSfreakie op 07-06-2011 11:47]

[timberleek]

SMSfreakie schreef op dinsdag 07 juni 2011 @ 11:46:
k heb hier een singlecore 1640LE met 1GB staan met FreeBSD en samba 3.3.8..(waarop FreeNAS gebaseerd is.. ) zonder byzondere instellingen.. en dat trekt gewoon tegen de 900MBIT/s zowel read als write

kijk dat wil ik dus ook


daar heb ik ook nog aan gedacht.
die freenas server gebruikt ufs formaat en mijn computer ntfs

ik probeerde net een paar gb te kopieren (die niet in transmission open stond). bij een snelheid van 15-20Mbit is de cpu load iets meer als 25%"

[Voor 34% gewijzigd door timberleek op 07-06-2011 16:48]

[SMSfreakie]

timberleek schreef op dinsdag 07 juni 2011 @ 16:45:
[...]

kijk dat wil ik dus ook


daar heb ik ook nog aan gedacht.
die freenas server gebruikt ufs formaat en mijn computer ntfs

ik probeerde net een paar gb te kopieren (die niet in transmission open stond). bij een snelheid van 15-20Mbit is de cpu load iets meer als 25%"
[afbeelding]

hmm.. hier is t FS op mn server ook UFS..

wat doet een

code:

 dd if=/dev/zero of=file1G.tmp bs=1M count=1024

voor resultaat geven op je server ?

1073741824 bytes transferred in 4.616601 secs (232582765 bytes/sec)

wat op zo`n 220MB/sec uit zou komen ( 2 Hitachi Deskstars 500GB in RAID 0 )

@ hieronder:

hmm je hebt gelijk...


nieuwe test

21474836480 bytes transferred in 152.001997 secs (141279963 bytes/sec)

nog +- 130MB/sec ( en gezien t een WRITE is.. en writes toch altijd lager uitvallen eigenlijks.. is het nog steeds ZAT voor GBIT )

[Voor 14% gewijzigd door SMSfreakie op 07-06-2011 17:29]

[borft]

houd bij dit soort testen wel rekening met de hoeveelheid geheugen in je machine. Eigenlijk moet je als je bv 1GB memory hebt, een file van 10GB schrijven om het effect van de kernel disk buffers zoveel mogelijk uit te schakelen.

Draai anders eens bonnie op de sschijven van je freenas om te zien of de diskperformance in order is. Met het tooltje iostat kan je zien wat de disk belasting is (bv iostat -xmcd 5) dan laat ie elke seconde de belasting van je schijven zien.

smb is een beetje een lastig protocol om mee te testen omdat er zoveel dingen kunnen zijn die de boel verzieken. Probeer bv eens ftp. Wat helemaal mooi zou zijn is een 2e linux machine. dan zou je met netcat en cstream kunnen testen.

[timberleek]

SMSfreakie schreef op dinsdag 07 juni 2011 @ 17:05:
[...]

code:

 dd if=/dev/zero of=file1G.tmp bs=1M count=1024

voor resultaat geven op je server ?

daar is hij het niet mee eens. ik krijg een write fail omdat het filesystem vol is.
waarschijnlijk is de usb stick te klein om freenas én dat bestand kwijt te kunnen (128mb stick).


er zit overigens 2GB ram in (1 plank)

iostat -c 20 geeft: (hou je vast)
(foto ipv een uur overtypen ;-)


edit: dit was natuurlijk terwijl hij aan het kopieren was
edit2: en ik kopieer steeds mappen met videobestanden can ca 8gb per map

ftp geeft ook ca 10MB/s
gewoon via ftp://ip adres freenas (in google chrome)

een bestand van 4.4gb gaat met 10MB/s ca 6min resterend
cpu load is dan max 10% zo te zien

[Voor 19% gewijzigd door timberleek op 07-06-2011 18:27]

[SMSfreakie]

moet je wel even op je storage medium doen he niet op je usbstik

[timberleek]

o sorry

maar hoe kom ik daar in.
ik heb de nas op een ander scherm aangesloten.

als ik dan de shell open staat hij automatisch in directory freenas.
maar ik moet naar mnt om bij de schijven te komen.
in freenas:~# staan 4 bestanden volgens het ls command:
.cshrc
.dialogrc
.profile
.file1G.tmp

als ik in de freenas webpagina zit en ga zoeken in de file editor kom ik die laatste tegen in de map root.
als dat de map is waar de shell in opent moet ik naar de bovenliggende map. dan naar mnt en daar staan de schijven...

hoe doe ik dat, of hoe kom ik waar ik moet zijn?

[SMSfreakie]

gewoon met cd /mnt

( waar /mnt je schijf is ( kan dus ook wat anders zijn.. gfi hoe FreeNAS dat verder indeeld.. )

[Voor 39% gewijzigd door SMSfreakie op 08-06-2011 00:45]

[timberleek]

ah kijk

nu ben ik ergens

in mnt zitten de 2 schijven (NAS share en storage2)

van die laatste krijg ik de volgende info:
1024+0 records in en uit
telkens 1073741824 Bytes verzonden
met de volgende snelheden:
11.94 seconden (89917584 Bytes/sec)
10.26 seconden (104641083 bytes/sec)
10.36 seconden (103606261 bytes/sec)
9.97 seconden (107656016 bytes/sec)

ja inderdaad 4 maal gedaan
de eerste keer moest de hd eerst nog opspinnen (stond standby). daardoor zal hij wel wat langzamer zijn geweest)

bij de eerste schijf:
(waar transmission ook draait atm, max 150kbit down en 50 kbit up):
20.86 sec (51465690 bytes/s)
20.66 sec (51969554 B/s)
17.82 sec (60254030 B/s)

[SMSfreakie]

hm.. met een 1GBtest gaat dus best redelijk op je snelste schijf

kan je hem ook met count=8192 doen?

dus:

code:

 dd if=/dev/zero of=file1G.tmp bs=1M count=8192

je disk met transmission is sowieso al bijna een keer zo traag als de andere ( dunno als dat door Transmission komt zou je moeten testen zonder dattie loopt )

[timberleek]

ik zal transmission eens uitzetten en het dan nog eens proberen op die hogere count

momentje

[EvilWhiteDragon]

Andere mogelijkheid, staat de data een beetje sequentieel op de schijf of juist niet? Als er veel seek acties plaatsvinden dan knalt dat enorm in je read speeds.

[SMSfreakie]

EvilWhiteDragon schreef op woensdag 08 juni 2011 @ 16:41:
Andere mogelijkheid, staat de data een beetje sequentieel op de schijf of juist niet? Als er veel seek acties plaatsvinden dan knalt dat enorm in je read speeds.

moauw ik weet zeker dat de data op mijn storage bak ook zwaar gefragmenteerd is.. maar dat geeft nog steeds niet zulke dramatische prestaties...

[timberleek]

de 'langzame' schijf geeft : (count = 8192, transmission is uitgeschakeld):
131.07 - 34.71 - 130.16 - 135.89 sec
65539247 - 63764317 - 65993987 - 63208306 bytes/sec

de andere schijf geeft:
94.18 - 85.77 - 82.59 sec
63208306 - 100150508 - 104006748 bytes/sec


misschien is de sequentiele data een reden dat het maandag ineens wel sneller ging.
die bestanden had ik op een andere computer staan en die had ik helemaal aan het begin van het installeren van de server op de schijf gezet. die stonden dus lekker op een rijtje. de rest van de data is er neergezet door transmission. die zal het lekker door elkaar hebben gezet omdat de transfers tegelijk aan stonden.

maar dat is misschien wel te testen.
als ik de data nu van de 2e schijf terugzet op de eerste. dan zou het sequentieel moeten gaan staan toch?
als ik hem dan weer naar de 2e schijf kopieer moet het sneller gaan.

maar dan nog kreeg ik maandag nog maar 10-20MB.

terwijl alles een Gbit nic heeft. allemaal cat6 stp bekabeling en een tplink sg1008 gbit switch.

o wacht, mijn desktop heeft nog een onbekende kabel. hij wordt wel herkent als Gbit, maar voor de zekerheid heb ik er even een ander in geprikt. ik zal nog een keer kopieren om te kijken of de snelheid nu omhoog gaat

edit:
terug kopieren van de 2e naar de eerste schijf geeft 23MB/s
daarna van schijf 1 naar schijf 2 geeft ongeveer hetzelfde resultaat (21-23MB)

[Voor 4% gewijzigd door timberleek op 08-06-2011 17:28]

[SMSfreakie]

hmz.. je gigabit adapters.. zijn die op een PCI of PCI-E bus gekoppeld weet je dat zo?

edit: op je Server lijkt t me een PCI-E model te zijn (de onboard dan..) je desktop kan ik aan de hand van de gegevens niet achterhalen

[Voor 45% gewijzigd door SMSfreakie op 08-06-2011 18:52]

[timberleek]

die in mijn desktop is pci ipv pci-x(zoveel)
dat is een "level one gnc-0105T 32bit/10/100/1000Mbps ethernet pci card"
geschikt voor full duplex staat erop

Die in mijn server is onboard.

[mace]

Tsurany schreef op vrijdag 03 juni 2011 @ 22:04:
Dat klopt, dat is niet correct. Een switch houd in een tabel bij welke IP adressen aan welk MAC adres vast zit en kan zo dus het verkeer doorsturen naar de juiste poort. Het gaat dus gewoon van homeserver via je switch direct naar je desktop toe.

Uhh. Nee.

Een switch is een layer 2 device en doet dus niks met IP.

[SMSfreakie]

timberleek schreef op woensdag 08 juni 2011 @ 18:51:
die in mijn desktop is pci ipv pci-x(zoveel)
dat is een "level one gnc-0105T 32bit/10/100/1000Mbps ethernet pci card"
geschikt voor full duplex staat erop

Die in mijn server is onboard.

goed.. 1 PCI-E (onboard van je server )
en je desktop heeft dus een PCI kaart..

mijn ervaring in het verleden was dat een PCI versie duidelijk trager presteerd dan een PCI-E model

( intel PRO/1000 in zowel PCI als PCI-E getest.. de PCI versie bleef regelmatig rond de 25MB/sec hangen.. het PCI-E model (welke ik nog steeds gebruik in mn server) trekt tegen de 100MB/sec.)

weet niet als je nog een ander systeem hebt welke een PCI-E GBIT adapter heeft? en je even kan gebruiken als test.. kunnen we evt dat soort dingen uitsluiten

[timberleek]

ik kan het nog eens proberen met mijn laptop. die heeft ook Gbit.
Een elitebook met intel gigabit controller (weet niet meer welke)

[CodeCaster]

timberleek schreef op dinsdag 07 juni 2011 @ 18:16:
waarschijnlijk is de usb stick te klein om freenas én dat bestand kwijt te kunnen (128mb stick).

Heel vreemd idee hoor, maar heeft samba niet toevallig een cachefolder op die usb-stick waardoor het lezen en schrijven zo langzaam gaat?

En heb je het al eens met een rechtstreekse verbinding (dus zonder switch ertussen) geprobeerd? De meeste netwerkkaarten zijn tegenwoordig toch wel auto-mdix dus een crosskabel heb je daar ook niet voor nodig.

[timberleek]

geen idee of de usb stick er snel genoeg voor is. het is een heel oud beestje. hij is ook altijd ca 5 min bezig met opstarten.

maar hoe zou ik dat kunnen controleren (zoals jullie zien ben ik een aardige linux/freebsd/unix leek)

ik heb het nog niet rechtstreeks geprobeerd, dat kan ik eens proberen.
en ik probeer het nog even per laptop

edit:
rechtstreeks een kabel tussen de 2 zorgt voor geen verbinding. duidelijk willen deze controllers niet zelf 'nadenken'

ik heb alleen geen crosscable. ik had eerste en koppelstukje, maar die kan ik niet vinden. ik betwijfel wel of dat een gbit versie is. zou zomaar een 4 pin kunnen zijn.

van de snelle schijf naar mijn laptop kopieren gaat met 50MB/s (via draad natuurlijk).
nog geen Gbit, maar al een stuk beter.
de cpu load zit dan rond de 50%

er zit dus wel een bottleneck bij de computer

[Voor 42% gewijzigd door timberleek op 08-06-2011 21:50]

[SMSfreakie]

timberleek schreef op woensdag 08 juni 2011 @ 21:33:
geen idee of de usb stick er snel genoeg voor is. het is een heel oud beestje. hij is ook altijd ca 5 min bezig met opstarten.

maar hoe zou ik dat kunnen controleren (zoals jullie zien ben ik een aardige linux/freebsd/unix leek)

ik heb het nog niet rechtstreeks geprobeerd, dat kan ik eens proberen.
en ik probeer het nog even per laptop

edit:
rechtstreeks een kabel tussen de 2 zorgt voor geen verbinding. duidelijk willen deze controllers niet zelf 'nadenken'

ik heb alleen geen crosscable. ik had eerste en koppelstukje, maar die kan ik niet vinden. ik betwijfel wel of dat een gbit versie is. zou zomaar een 4 pin kunnen zijn.

van de snelle schijf naar mijn laptop kopieren gaat met 50MB/s (via draad natuurlijk).
nog geen Gbit, maar al een stuk beter.
de cpu load zit dan rond de 50%

er zit dus wel een bottleneck bij de computer

50MB/s is waarsch de laptop hdd die dan de bottle neck word

* SMSfreakie gokt op dat de PCI nic t niet bij kan benen... (en persoonlijk zou ik die vervangen voor een PCI-E model )

[timberleek]

!@#$%
hopelijk kan ik ze nog terugbrengen.

ik heb met mijn stomme kop natuurlijk geen bon meegenomen.
gelukkig nog wel een pinbon en de originele verpakking.
kan het altijd proberen

ik zou het eens kunnen proberen met de onboard nic van mijn desktop.
hij is weliswaar 100Mbit, maar dat moet dan wel een heel eind te bereiken zijn

edit:
ja hoor, op de 100mbit nic krijg ik gewoon 11-11.5MB --> ca 90mbit. daar kan ik niet over klagen imo

[Voor 42% gewijzigd door timberleek op 08-06-2011 23:56]

[SMSfreakie]

timberleek schreef op woensdag 08 juni 2011 @ 23:24:
!@#$%
hopelijk kan ik ze nog terugbrengen.

ik heb met mijn stomme kop natuurlijk geen bon meegenomen.
gelukkig nog wel een pinbon en de originele verpakking.
kan het altijd proberen

ik zou het eens kunnen proberen met de onboard nic van mijn desktop.
hij is weliswaar 100Mbit, maar dat moet dan wel een heel eind te bereiken zijn

edit:
ja hoor, op de 100mbit nic krijg ik gewoon 11-11.5MB --> ca 90mbit. daar kan ik niet over klagen imo

mja.. 100mbit is natuurlijk peanuts

[timberleek]

dat klopt, maar het was even ter controle;-)

[timberleek]

ik ben weer het een en ander aan het kopieren.
maar zo te zien blijft er wel communicatie me de router.

mijn laptop en de server zitten beide op dezelfde switch. je zou denken dat hij dan gewoon via de switch rechtstreeks door gaat, maar de led bij de kabelaansluiting die naar de 2e router loopt ((zonder dhcp) welke weer vast zit aan de eerste router) knippert vrolijk mee met de andere

[Gomez12]

timberleek schreef op zaterdag 11 juni 2011 @ 15:29:
ik ben weer het een en ander aan het kopieren.
maar zo te zien blijft er wel communicatie me de router.

mijn laptop en de server zitten beide op dezelfde switch. je zou denken dat hij dan gewoon via de switch rechtstreeks door gaat, maar de led bij de kabelaansluiting die naar de 2e router loopt ((zonder dhcp) welke weer vast zit aan de eerste router) knippert vrolijk mee met de andere

Kabel eruit en je weet het...

[timberleek]

nope ook met de kabel eruit blijft de snelheid hetzelfde

[K4F]

excuses, verkeerde topic.

[Voor 97% gewijzigd door K4F op 11-06-2011 20:42]