Toon posts:

pings lopen op in de tijd bij Linux server

Pagina: 1
Acties:

Verwijderd

Topicstarter
RH 6.0 als server. Basis-installatie: Sendmail/ftp/apache/samba/Appletalk/network. De firewall op basis van PMFirewall lijkt probleemloos te werken.
Systeem doet het op zich goed. Alleen; de pings lopen op. ik moet nog een keer een log maken hoe snel maar het lijkt erg verschillend. Soms na 30 minuten, soms pas na een nacht.
Alleen al het network restart commando is al voldoende om weer normale pings te krijgen (zonder de firewall te herstarten.
Suggesties welkom.

PS: het gebruik van systeem resources is erg laag. Alles draait in pure textmode zonder grafische interface (kan wel handmatig gestart worden).

Verwijderd

Topicstarter
inmiddels heb ik wel al de samba opzet verbeterd. Het vermoeden bestaat dat er toch een "storm luwt op het netwerk".
Ik denk.... een stap verder te zijn: vanmorgen moest ik een netwerk herstart commando geven, maar nu is het herstarten van een ping al voldoende. Ik ping 1x per 10s dus dat is geen belasting. Maar.... het loopt nog steeds op.
Uiteraard meet je dit ook op de clients.
Je ziet daar enorm verschillen in pings; van timeout tot 20ms. Maar vanmiddag na ca 2 uren had ik op de server zelfs een ping van 65000 ms.....
Tip?

smb.conf met het belangrijkste gedeelte.
# Global parameters
[global]
workgroup = samba
server string = Samba Server
# hosts allow = 192.168.0. 127.0.0. uitgezet:anders werkt swat niet
log file = /var/log/samba/log.%m
max log size = 50
socket options = TCP_NODELAY SO_KEEPALIVE SO_SNDBUF=8192 SO_RCVBUF=8192
printcap name = /etc/printcap
dns proxy = No
guest account = nobody
hide dot files = yes
status = yes
strict locking = yes
print command = lpr -r -P%p %s
lpq command = lpq -P%p
lprm command = lprm -P%p %j
comment = home.chello.nl
encrypt passwords = no
password level = 0
preferred master = no
os level = 0
null passwords = no
dead time = 0
debug level = 0
domain master = no
load printers = no

en hosts:
127.0.0.1 localhost localhost.localdomain
192.168.0.1 home home.plaats.chello.nl

Verwijderd

Topicstarter
weer eens stap verder: Apache en samba uitgezet.
De pings blijven oplopen na een herstart.
Als je naar de output van ifonfig kijkt, dan lijkt alles normaal. Op het (grote) aaantal pakketjes dat verstuurd wordt, geeft eth0 47 collisions en eth1 114.
Tips blijven welkom.

Verwijderd

Topicstarter
De laatste posting gaf mij steeds meer het vermoeden dat het niet aan deze server lag.....
Helaas, mijn Freesco server vertoont nu ook zulke kuren, weliswaar zijn de pings geen 65000 maar toch al 800.
De lijnmonitor geeft weliswaar aan dat er op sommige tijden 10-20% verlies was, maar dat was lang niet altijd.

Wat is nu wijsheid? Chello of toch de server, immers bij herstarten zijn de pings meestal weer goed. Toch nog een instelling verkeerd? Wel vreemd want de Freesco server heeft het (ook) altijd goed gedaan.
Iemand een tip?

  • Ronald
  • Registratie: Juli 2000
  • Laatst online: 02:14
zet alle services uit (samba apcahe sendmail etc)
kijk of de ping dan goed blijft. zo ja dan 1 service tegelijk aanzetten en kijken, totdat je weet welke service er brak loopt.

PV Output - Obdam; SolarEdge SE5K 'Voor korte strings'; 12x350Wp Oost-West 13°; 8x415Wp Zuid 10°; Totaal 7520Wp.


Verwijderd

Topicstarter
had ik deels gedaan.
Ik heb nu een andere test gedaan: van 1x 3c509 en 1x ne2000 vervangen door 2x 3c509. Alles weer opnieuw ingesteld, maar nu vben ik mijn loklae netwerk kwijt terwijl ik de lokale kaart wel kan pingen.
Wat wel opvalt is dat nu weliswaar err geen collisions zijn, maar de irq en i/o gegevens er niet bij staan.
Ik denk dat ik dus een hardware probleem heb. Dus kan weer verder.

Verwijderd

Topicstarter
andere NE2000-compatible erin.....geen verbetering (toch een aantal collisions).
Maar nu werkt het toch al een aantal uren na een herstart.
Ik was er niet en mijn zoon heeft het netwerk gereset omdat het zo traag was. Heeft ook weer een ping insteld hoe het nu verloopt. Tot nu toe goed. Ik heb een donkerbruin vermoeden, maar eerst maar eerst een nachtje draaien....

Verwijderd

Topicstarter
na een nacht bere-stabiel.
Wat lijkt het geweest?
Voor de migratie van Chello in september, had ik altijd een log van pings van Chello (met een interval: ping -i 10 212.143.29.66 dus 1 ping per 10s).
Dan kon je mooi zien wanneer er problemen waren met de server. De verbinding met Chello zelf was hier vrijwel altijd goed. Na de migratie begonnen de problemen met Linux. Windows geen probleem, maar ja ik wilde linux, immers het had bijna een jaar problemeloos gedraaid. Uiteindelijk bleek dat het gateway IP-nr ingevuld moet worden (Freesco had hetzelfde maco, bij windows hoefde dat niet... gebeurt automatisch).
Toen deze problemen achter de rug waren, werkte alles weer goed en...... natuurlijk mijn ping log van Chello weer ingesteld. Tot een paar weken geleden, telkens een herstart nodig was om van die hoge pings en traagheid af te komen.
Daarna heb ik van alles gedaan, zie boven....
Totdat mijn zoon gisteren herstartte en ook een ping instelde maar van google...... Sindsdien lijkt het bere-stabiel.
Voorlopige conlusie: het pingen van de Chello server lijkt een destreus effect te hebben op de kwaliteit van de verbinding.

Zijn er meer mensen met zulke ervaringen?







De ping details:
ping 212.143.29.66
PING 212.143.29.66 (212.143.29.66): 56 data bytes
64 bytes from 212.143.29.66: icmp_seq=3 ttl=64 time=59.3 ms
64 bytes from 212.143.29.66: icmp_seq=0 ttl=64 time=3060.0 ms
64 bytes from 212.143.29.66: icmp_seq=1 ttl=64 time=2064.3 ms
64 bytes from 212.143.29.66: icmp_seq=2 ttl=64 time=1066.3 ms
64 bytes from 212.143.29.66: icmp_seq=4 ttl=64 time=25024.6 ms
64 bytes from 212.143.29.66: icmp_seq=5 ttl=64 time=24027.2 ms
64 bytes from 212.143.29.66: icmp_seq=6 ttl=64 time=23029.2 ms
64 bytes from 212.143.29.66: icmp_seq=7 ttl=64 time=22031.3 ms
64 bytes from 212.143.29.66: icmp_seq=8 ttl=64 time=21032.8 ms
64 bytes from 212.143.29.66: icmp_seq=9 ttl=64 time=20034.7 ms
64 bytes from 212.143.29.66: icmp_seq=10 ttl=64 time=19036.7 ms
64 bytes from 212.143.29.66: icmp_seq=11 ttl=64 time=18038.6 ms
64 bytes from 212.143.29.66: icmp_seq=12 ttl=64 time=17040.7 ms
64 bytes from 212.143.29.66: icmp_seq=13 ttl=64 time=16042.6 ms
64 bytes from 212.143.29.66: icmp_seq=60 ttl=64 time=29.5 ms
64 bytes from 212.143.29.66: icmp_seq=29 ttl=64 time=31030.9 ms
64 bytes from 212.143.29.66: icmp_seq=30 ttl=64 time=30034.3 ms
64 bytes from 212.143.29.66: icmp_seq=31 ttl=64 time=29036.2 ms
64 bytes from 212.143.29.66: icmp_seq=32 ttl=64 time=28038.2 ms
64 bytes from 212.143.29.66: icmp_seq=33 ttl=64 time=27040.2 ms
64 bytes from 212.143.29.66: icmp_seq=34 ttl=64 time=26042.1 ms
64 bytes from 212.143.29.66: icmp_seq=35 ttl=64 time=25044.1 ms
64 bytes from 212.143.29.66: icmp_seq=36 ttl=64 time=24046.0 ms
64 bytes from 212.143.29.66: icmp_seq=37 ttl=64 time=23047.9 ms
64 bytes from 212.143.29.66: icmp_seq=38 ttl=64 time=22050.0 ms
64 bytes from 212.143.29.66: icmp_seq=39 ttl=64 time=21051.9 ms
64 bytes from 212.143.29.66: icmp_seq=40 ttl=64 time=20053.8 ms
64 bytes from 212.143.29.66: icmp_seq=41 ttl=64 time=19056.9 ms
64 bytes from 212.143.29.66: icmp_seq=42 ttl=64 time=18060.4 ms
64 bytes from 212.143.29.66: icmp_seq=43 ttl=64 time=17062.3 ms
64 bytes from 212.143.29.66: icmp_seq=44 ttl=64 time=16064.3 ms
64 bytes from 212.143.29.66: icmp_seq=45 ttl=64 time=15066.2 ms
64 bytes from 212.143.29.66: icmp_seq=46 ttl=64 time=14068.1 ms
64 bytes from 212.143.29.66: icmp_seq=47 ttl=64 time=13070.2 ms
64 bytes from 212.143.29.66: icmp_seq=48 ttl=64 time=12072.1 ms
64 bytes from 212.143.29.66: icmp_seq=49 ttl=64 time=11074.0 ms
64 bytes from 212.143.29.66: icmp_seq=50 ttl=64 time=10076.0 ms
64 bytes from 212.143.29.66: icmp_seq=51 ttl=64 time=9077.9 ms
64 bytes from 212.143.29.66: icmp_seq=52 ttl=64 time=8079.9 ms
64 bytes from 212.143.29.66: icmp_seq=53 ttl=64 time=7081.9 ms
64 bytes from 212.143.29.66: icmp_seq=54 ttl=64 time=6085.1 ms
64 bytes from 212.143.29.66: icmp_seq=55 ttl=64 time=5088.4 ms
64 bytes from 212.143.29.66: icmp_seq=56 ttl=64 time=4090.5 ms
64 bytes from 212.143.29.66: icmp_seq=57 ttl=64 time=3092.5 ms
64 bytes from 212.143.29.66: icmp_seq=58 ttl=64 time=2094.4 ms
64 bytes from 212.143.29.66: icmp_seq=59 ttl=64 time=1096.3 ms

Dus: de Chello-server verzamelt pakketjes (die per seconde worden verstuurd)
om ze dan opeens allemaal te beantwoorden. Daarbij krijg je het pakket
dat ie als laatste ontving als eerste terug (pakket 3 en pakket 60),
en de rest daarna wel in de logische volgorde: de oudste als eerste.

Na een herstart :

ping 212.143.29.66
PING 212.143.29.66 (212.143.29.66): 56 data bytes
64 bytes from 212.143.29.66: icmp_seq=0 ttl=64 time=24.2 ms
64 bytes from 212.143.29.66: icmp_seq=1 ttl=64 time=27.1 ms
64 bytes from 212.143.29.66: icmp_seq=2 ttl=64 time=29.4 ms
64 bytes from 212.143.29.66: icmp_seq=3 ttl=64 time=25.9 ms
64 bytes from 212.143.29.66: icmp_seq=4 ttl=64 time=28.3 ms
Pagina: 1