Performanceprobleme Soekris

Manga

Well-Known Member
Hallo,

ich hab ein paar Performanceprobleme mit meiner soekris 4801-50.
(FBSD 6.1-release)


Ich bekomme nur ~750k Durchsatz beim ftp-transfer.
Mit netio siehts auch nicht viel besser aus.

Was mich allerdings wundert, ist das wenn ich netio mit
ziel "localhost" ausführe, 3-mal höheren Durchsatz habe,
und die Interruptlast nur halb so hoch ist,
als wenn ich die entsprechende IP verwende.

Die Namesaüflösung hab ich laut wiki eingestellt, und das System reagiert eigentlich auch sehr schnell.

Im Anhang hab ich mal ein paar Testergebnisse und die Einstellungen der rc.conf, etc.


Code:
-----------------------------------------------------
gstsat.

dT: 0.514  flag_I 500000us  sizeof 240  i -1
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    0      6      0      0    0.0      6    747    6.9    4.1| ad0
    0      6      0      0    0.0      6    747    7.0    4.1| ad0s1
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1a
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1b
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1c
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1d
    0      0      0      0    0.0      0      0    0.0    0.0| ad0s1e
    0      6      0      0    0.0      6    747    7.2    4.2| ad0s1f



227 Entering Passive Mode (192,168,0,11,6,121).
150 Opening data connection for plan9.iso.bz2.
 48% |*****************                    | 36117 KB  752.41 KB/s    00:51 ETA

------------------------------------------------------------------------------
Code:
localhost# netio localhost
NETIO - Network Throughput Benchmark, Version 1.14
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size  1 KByte:   6022 KByte/s
Packet size  2 KByte:   7134 KByte/s
Packet size  4 KByte:   7466 KByte/s
Packet size  8 KByte:   7486 KByte/s
Packet size 16 KByte:   7568 KByte/s
Packet size 32 KByte:   8081 KByte/s


last pid:   776;  load averages:  0.83,  0.82,  0.53    up 0+01:03:55  17:17:54
39 processes:  2 running, 37 sleeping
CPU states:  2.3% user,  0.0% nice, 72.5% system, 25.2% interrupt,  0.0% idle
Mem: 22M Active, 29M Inact, 28M Wired, 7272K Cache, 22M Buf, 31M Free
Swap: 2021M Total, 2021M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
  775 root        1 112    0  1252K   688K RUN      0:10 46.70% netio
  688 root        1   4    0  1220K   664K sbwait   1:00 14.40% netio
  776 root        1  96    0  2268K  1332K RUN      0:00  0.56% top
  562 root        1   5    0  1940K  1252K ttyin    0:22  0.00% ftp
  628 user1        1  96    0  6080K  2264K select   0:01  0.00% sshd
  345 root        1  96    0  1300K   860K select   0:00  0.00% syslogd
  625 root        1   4    0  6104K  2252K sbwait   0:00  0.00% sshd
  761 root        1   4    0  6104K  2396K sbwait   0:00  0.00% sshd
  648 root        1   4    0  6104K  2252K sbwait   0:00  0.00% sshd
  494 root        1  96    0  3420K  2020K select   0:00  0.00% sendmail
  651 user1        1  96    0  6080K  2256K select   0:00  0.00% sshd
  727 root        1  20    0  4724K  2504K pause    0:00  0.00% csh
  629 user1        1  20    0  4696K  2356K pause    0:00  0.00% tcsh
  655 root        1  20    0  4724K  2324K pause    0:00  0.00% csh
  559 root        1  20    0  4596K  2372K pause    0:00  0.00% csh
  770 root        1  20    0  4724K  2536K pause    0:00  0.00% csh
  652 user1        1  20    0  4564K  2272K pause    0:00  0.00% tcsh
Code:
localhost# netio 192.168.0.12	// = localhost

NETIO - Network Throughput Benchmark, Version 1.14
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size  1 KByte:   2066 KByte/s
Packet size  2 KByte:   2203 KByte/s
Packet size  4 KByte:   2267 KByte/s
Packet size  8 KByte:   2294 KByte/s
Packet size 16 KByte:   2307 KByte/s
Packet size 32 KByte:   2303 KByte/s


last pid:   774;  load averages:  1.27,  0.83,  0.49    up 0+01:01:36  17:15:35
39 processes:  2 running, 37 sleeping
CPU states:  1.2% user,  0.0% nice, 46.3% system, 52.5% interrupt,  0.0% idle
Mem: 22M Active, 29M Inact, 28M Wired, 7272K Cache, 22M Buf, 31M Free
Swap: 2021M Total, 2021M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
  774 root        1 108    0  1220K   576K RUN      0:04 28.78% netio
  688 root        1   4    0  1220K   664K sbwait   0:46 13.77% netio
  773 root        1  96    0  2268K  1332K RUN      0:00  0.08% top
  562 root        1   5    0  1940K  1252K ttyin    0:22  0.00% ftp
  628 user1        1  96    0  6080K  2264K select   0:01  0.00% sshd
  345 root        1  96    0  1300K   860K select   0:00  0.00% syslogd
  625 root        1   4    0  6104K  2252K sbwait   0:00  0.00% sshd
  761 root        1   4    0  6104K  2396K sbwait   0:00  0.00% sshd
  648 root        1   4    0  6104K  2252K sbwait   0:00  0.00% sshd
  494 root        1  96    0  3420K  2020K select   0:00  0.00% sendmail
  651 user1        1  96    0  6080K  2256K select   0:00  0.00% sshd
  629 user1        1  20    0  4696K  2356K pause    0:00  0.00% tcsh
  727 root        1  20    0  4724K  2504K pause    0:00  0.00% csh
  655 root        1  20    0  4724K  2324K pause    0:00  0.00% csh
  559 root        1  20    0  4596K  2372K pause    0:00  0.00% csh
  652 user1        1  20    0  4564K  2272K pause    0:00  0.00% tcsh
  770 root        1  20    0  4596K  2532K pause    0:00  0.00% csh


Code:
netio anderer rechner:


localhost# netio 192.168.0.14

NETIO - Network Throughput Benchmark, Version 1.14
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size  1 KByte:   1063 KByte/s
Packet size  2 KByte:   995 KByte/s
Packet size  4 KByte:   1077 KByte/s
Packet size  8 KByte:   1077 KByte/s
Packet size 16 KByte:   1081 KByte/s
Packet size 32 KByte:   1018 KByte/s


Code:
rc.conf:

hostname="localhost.example.test"

etc/hosts

::1                     localhost localhost.example.test
127.0.0.1               localhost localhost.example.test

--------------------------------------

mit dhcp und hostname in rc.conf ausgeklammert

# hostname

# host localhost
localhost has address 127.0.0.1
Host localhost not found: 3(NXDOMAIN)
# host 192.168.0.12
12.0.168.192.in-addr.arpa has no PTR record
#

ohne dhcp mit hostname in rc.conf

localhost# hostname
localhost.example.test
localhost# host localhost
localhost has address 127.0.0.1
Host localhost not found: 3(NXDOMAIN)
localhost# host 192.168.0.12
12.0.168.192.in-addr.arpa has no PTR record
localhost#


Das kommt mir auch für ne Soekris recht wenig vor.
Welche Werte erreicht ihr ungefähr mit eurer Kiste, und an was kann
der geringe Durchsatz liegen?



mfg
 
auf einem wrap mit netbsd kriege ich per http nach /dev/null das:

130547712 bytes retrieved in 00:41 (3.02 MB/s)

also etwas mehr als 700K sollte schon drin sein, auch wenn die geodes keine leistungswunder sind.
 
naja,

auf der monowall homepage wird mit 54Mbit geworben.
die 750kb/s sind da schon recht enttäuchend. :(

5-6 Mb/s hätt ich schon erwartet...
 
Hallo,

hab mich gerade mal an polling versucht, aber ich bekomms nicht ans Laufen.

ifconfig sis0 polling bringt ein "ifconfig: polling: Invalid argument"
und ein "sysctl -A | grep polling" gibt nichts zurück, obwohl es laut manpage einige MIBs geben sollte..
 
# sysctl -a | grep polling
kern.polling.idlepoll_sleeping: 1
kern.polling.stalled: 0
kern.polling.suspect: 0
kern.polling.phase: 0
kern.polling.enable: 0
kern.polling.handlers: 0
kern.polling.residual_burst: 0
kern.polling.pending_polls: 0
kern.polling.lost_polls: 0
kern.polling.short_ticks: 0
kern.polling.reg_frac: 20
kern.polling.user_frac: 50
kern.polling.poll_in_trap: 0
kern.polling.idle_poll: 0
kern.polling.burst_max: 150
kern.polling.each_burst: 5
kern.polling.burst: 5
 
localhost# uname -a
FreeBSD localhost.example.test 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04
:42:56 UTC 2006 root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386

localhost# sysctl -a | grep polling
localhost#


???
 
Wat zum Geier willst Du mit einem SMP Kernel auf ner Soekris?
Code:
machine     i386
cpu     I586_CPU
options     CPU_SOEKRIS
 
hmm,

hab eigentlich ganz normal installiert wie immer...
wo kommt der denn her?
Ist das jetz der Standardkernel?
Und wo liegt der normale rum? Ich wollte eigentlich ums kompilieren rumkommen.
auf der Kiste könnte das etwas dauern.

Und liegt es daran, das kein polling unterstützt wird?


EDIT:

Ok,

ich glaub ich mach mich mal an kernel config datei..
hoffentlich dauerts weniger als 24 Stunden :(
 
Zuletzt bearbeitet:
Manga schrieb:
ein "sysctl -A | grep polling" gibt nichts zurück, obwohl es laut manpage einige MIBs geben sollte..
In /usr/src/sys/i386/conf/NOTES wird ein "DEVICE_POLLING" erwähnt.

HTH & Ciao.
Markus Mann
];-)
 
Manga schrieb:
hab eigentlich ganz normal installiert wie immer...
wo kommt der denn her?
Ist das jetz der Standardkernel?
Und wo liegt der normale rum? Ich wollte eigentlich ums kompilieren rumkommen.
auf der Kiste könnte das etwas dauern.

Du hast jetzt nicht wirklich einfach ein stinkenormales FreeBSD mit GENERIC oder gar SMP Kernel da einfach auf das net4801 gespielt und wunderst Dich, dass da Probleme auftreten?

Da musst Du schon mal den Kernel bissel anpassen. Ich weiss nicht, ob das der Grund fuer Dein Performanceproblem ist. Ich weiss aber, dass ich z.B. folgendes im Soekris Kernel habe:

Code:
options         CPU_GEODE                                                                                                                             
options         CPU_SOEKRIS        
options         DEVICE_POLLING                                                                                                                 
options         CLK_USE_I8254_CALIBRATION
 
So,

habe nun mal einen angepassten Kernel erstellt,
und oh Wunder - polling ist vorhanden.

Die Leistung duch den angepassten Kernel ist um ca. 3-4 Prozent gestiegen.
Allerdings schein polling eher kontraproduktiv.
Nach Aktivierung sinkt der Durchsatz um ca 15-20 Prozent.

Ich hab mit kern.polling.user_frac und kern.polling.reg_frac rumprobiert,
allerdings ohne signifikante Änderung.
Ich weiss nicht ob das die richtigen Parameter sind, aber es schienen
die einzig brauchbaren zu sein.

Was ich mir immer noch nicht erklären kann, ist der riesen Unterschied
im Durchsatz wenn ich "localhost", statt die IP des Rechners verwende.
Vielleicht liegt da der Hund begraben, aber ich hab keine Ahnung wo ich suchen sollte.
 
Manga schrieb:
Was ich mir immer noch nicht erklären kann, ist der riesen Unterschied
im Durchsatz wenn ich "localhost", statt die IP des Rechners verwende.
Vielleicht liegt da der Hund begraben, aber ich hab keine Ahnung wo ich suchen sollte.

<vermutung>
Vlt. liegst an der Namensaufloesung? Hast du dir den Artikel im Wiki dazu mal angeschaut?
</vermutung>
 
Die Namesauflösung hab ich laut wiki eingestellt
(siehe Post 1 letzter Block)

Ich nehm an, die Fehlermeldungen kommen daher, das hier kein DNS Server läuft.
 
Die Namensauflösung verursacht evtl ein anfängliches delay, aber ganz sicher keinen verminderten Durchsatz im Dauerbetrieb!

Bei den kleinen Kisten lohnt sich ein angepasstes FreeBSD mit minimalem Kernel und services.
Device polling, net.isr.direct=1 und net.inet.ip.process_options=1 als wichtigste Punkte die einem ins Auge springen. Danach mit netstat, sysctls und ähnlichem Flaschenhälse suchen und beheben.
 
So, hab nun noch den switch gewechselt,
nachdem ein Kabelwechsel nix brachte und der alte switch mit winxp
und meinem FreeBSD Laptop knapp 11MB/s brachte, scheint es trotzdem
daran gelgen zu haben.

Im Moment bekomme ich ca. 2,3 MB/s Durchsatz per ftp bzw netio,
(bei aktiviertem polling bis zu 3,1MB/s per ftp, aber dafür nur 1.8 bei netio??)
was ziemlich genau so viel ist, wie wenn ich den Durchsatz
über die IP messe (siehe erster Post).
Über localhost bekomme ich weiterhin gut 8MB/s.

Kann es sein, das bei netio xxx.xxx.xxx.xxx der Verkehr über das Interface (sis0)
geht und bei netio localhost über den loopback?
Eigentlich sollte doch der gesamte Verkehr über lo0 gehen, sobald der Name aufgelöst wurde, oder?

Ich hab mit polling und den anderen hier genannten MIB´s rumgespielt, meisst mit begrenztem Erfolg, aber ich denke nicht, das der Leistungsunterschied zwischen localhost und IP-Adresse daher kommt.


Vielleicht noch irgendwelche Ideen?
 
Manga schrieb:
Im Moment bekomme ich ca. 2,3 MB/s Durchsatz per ftp bzw netio,
(bei aktiviertem polling bis zu 3,1MB/s per ftp, aber dafür nur 1.8 bei netio??)

Deckt sich mit meinen Erfahrungswerten. Ohne Polling kannst Du mehr rausholen (um die 4MB/s) aber dann haelt das Soekris quasi an, sobald Last auf die NICs kommt. FreeBSD behandelt dann nur noch die Interrupts und sonst nichts mehr.
 
Hi,


wenn du sagst es funktionierte nach dem Switch-Tausch besser, dann tippe ich mal auf Autosensing-Problematik. Switch und Host sollten gleich eingestellt sein, sprich beide Autosensing oder beide 100 full-duplex.
Probier doch einfach mal aus ob ein

ifconfig sis0 media auto bzw.
ifconfig sis0 media 100baseTX mediaopt full-duplex

einen Performanceunterschied ausmachen.


Gruß,
*Flex*
 
Auf den alten switch hab ich im Moment keinen Zugriff.
Beim neuen hat das Umstellen auf media 100baseTX mediaopt full-duplex
den Effekt, das nur noch 1,6 statt 2,3 MB/sec durchgehen.
Auf halbduplex lässt sich die Karte gar nicht umstellen, obwohl sie das laut manpage können sollte:

localhost# ifconfig sis0 media 100baseTX mediaopt full-duplex
localhost# ifconfig sis0 media 100baseTX mediaopt half-duplex
ifconfig: SIOCSIFMEDIA (media): Device not configured
 
half-duplex ist keine option, die man extra angibt. die ist impliziert, wenn man mediaopt full-duplex weglaesst.

sollte so auch bei ifconfig -m sis0 stehen.
 
auf einem wrap mit netbsd kriege ich per http nach /dev/null das:

130547712 bytes retrieved in 00:41 (3.02 MB/s)

also etwas mehr als 700K sollte schon drin sein, auch wenn die geodes keine leistungswunder sind.
also entweder habe ich da mist gebaut oder netbsd -current ist irgendwie viel besser geworden. ich habe auf einmal ueber 5M/s per http nach /dev/null.
 
Nur ein Hinweis:

Einige NS-Chips, die auch auf den Geode verbaut wurden, haben ein Problem mit kurzen Leitungslängen.
Dazu wurde auch die betroffenen Chips im sis(4) Treiber anders initialisiert, wodurch das Problem gelindert bzw. behoben werden sollte.
Z.B. bei Revision 1.120 findet sich ein Hinweis darauf.

Theoretisch koennte durch kurze Kabel sehr viele kaputte Frames gelesen/gesendet werde, wodurch der Durchsatz sinkt und der Korrektur-Mechanismus die CPU-Last zieht.

Also: Versuche mal maximal lange Netzwerkkabel, es besteht eine kleine Chance, dass es dann besser wird.
 
Theoretisch koennte durch kurze Kabel sehr viele kaputte Frames gelesen/gesendet werde, wodurch der Durchsatz sinkt und der Korrektur-Mechanismus die CPU-Last zieht.
wuerde man die kaputten frames als errors in netstat sehen? denn dahingehend ist hier zumindest alles i.o., und ich nutze auch z.t. 50cm-kabel.
 
Zurück
Oben