[Nottingham] Odd behaviour in KDE
Lee
nottingham at mailman.lug.org.uk
Mon Aug 18 20:57:02 2003
hmm, your stats seems to show lots of ip fragments being sent/received,
do you have a weird mtu or something? probably nothing to do with it,
but strange perhaps?
Laters,
Lee
On Mon, 2003-08-18 at 20:29, Iain Lennon wrote:
> All my packages come from the 9.1 Mandrake
> Both Office comp and server have these packages:
> nfs-utils-1.0.1-1mdk
> nfs-utils-clients-1.0.1-1mdk
> portmap 4.0-20mdk (up and running)
>
> Tried this in Gnome, and got an I/O error at the same file size, but was able
> to complete uploading of the file after retrying
>
> Apologies for the long reports, I'm not up to interpreting this info: its
> outside my limited networking understanding!!
>
> Hope anyone has some ideas. I'll post any other log sections which people
> might find helpful
>
> Server netstat-s report
> Ip:
> 1923961 total packets received
> 184 forwarded
> 0 incoming packets discarded
> 1694051 incoming packets delivered
> 1704273 requests sent out
> 220 fragments dropped after timeout
> 2039526 reassemblies required
> 343627 packets reassembled ok
> 220 packet reassembles failed
> 303371 fragments received ok
> 3595184 fragments created
> Icmp:
> 5245 ICMP messages received
> 0 input ICMP message failed.
> ICMP input histogram:
> destination unreachable: 2239
> timeout in transit: 2828
> echo requests: 178
> 950 ICMP messages sent
> 0 ICMP messages failed
> ICMP output histogram:
> destination unreachable: 772
> echo replies: 178
> Tcp:
> 9120 active connections openings
> 5997 passive connection openings
> 0 failed connection attempts
> 0 connection resets received
> 11 connections established
> 616043 segments received
> 630237 segments send out
> 5551 segments retransmited
> 0 bad segments received.
> 1909 resets sent
> Udp:
> 1079628 packets received
> 734 packets to unknown port received.
> 0 packet receive errors
> 1073168 packets sent
> TcpExt:
> 3 resets received for embryonic SYN_RECV sockets
> 2 packets pruned from receive queue because of socket buffer overrun
> ArpFilter: 0
> 7415 TCP sockets finished time wait in fast timer
> 1 time wait sockets recycled by time stamp
> 16 packets rejects in established connections because of timestamp
> 10367 delayed acks sent
> 14 delayed acks further delayed because of locked socket
> Quick ack mode was activated 227 times
> 12735 packets directly queued to recvmsg prequeue.
> 53804 packets directly received from backlog
> 8541491 packets directly received from prequeue
> 209982 packets header predicted
> 10502 packets header predicted and directly queued to user
> TCPPureAcks: 44475
> TCPHPAcks: 187071
> TCPRenoRecovery: 0
> TCPSackRecovery: 765
> TCPSACKReneging: 0
> TCPFACKReorder: 0
> TCPSACKReorder: 0
> TCPRenoReorder: 0
> TCPTSReorder: 0
> TCPFullUndo: 0
> TCPPartialUndo: 0
> TCPDSACKUndo: 0
> TCPLossUndo: 161
> TCPLoss: 600
> TCPLostRetransmit: 0
> TCPRenoFailures: 0
> TCPSackFailures: 316
> TCPLossFailures: 2
> TCPFastRetrans: 772
> TCPForwardRetrans: 18
> TCPSlowStartRetrans: 17
> TCPTimeouts: 1168
> TCPRenoRecoveryFail: 0
> TCPSackRecoveryFail: 85
> TCPSchedulerFailed: 9
> TCPRcvCollapsed: 71
> TCPDSACKOldSent: 190
> TCPDSACKOfoSent: 0
> TCPDSACKRecv: 51
> TCPDSACKOfoRecv: 0
> TCPAbortOnSyn: 0
> TCPAbortOnData: 122
> TCPAbortOnClose: 9
> TCPAbortOnMemory: 0
> TCPAbortOnTimeout: 674
> TCPAbortOnLinger: 0
> TCPAbortFailed: 0
> TCPMemoryPressures: 0
>
> Server nfsstat
> erver rpc stats:
> calls badcalls badauth badclnt xdrcall
> 1053765 0 0 0 0
> Server nfs v2:
> null getattr setattr root lookup readlink
> 1 100% 0 0% 0 0% 0 0% 0 0% 0 0%
> read wrcache write create remove rename
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> link symlink mkdir rmdir readdir fsstat
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
>
> Server nfs v3:
> null getattr setattr lookup access readlink
> 1 0% 666957 63% 95 0% 39909 3% 227 0% 4 0%
> read write create mkdir symlink mknod
> 304111 28% 40279 3% 321 0% 27 0% 0 0% 0 0%
> remove rmdir rename link readdir readdirplus
> 13 0% 0 0% 42 0% 0 0% 929 0% 0 0%
> fsstat fsinfo pathconf commit
> 111 0% 111 0% 0 0% 627 0%
>
> Client rpc stats:
> calls retrans authrefrsh
> 0 0 0
> Client nfs v2:
> null getattr setattr root lookup readlink
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> read wrcache write create remove rename
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> link symlink mkdir rmdir readdir fsstat
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
>
> Client nfs v3:
> null getattr setattr lookup access readlink
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> read write create mkdir symlink mknod
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> remove rmdir rename link readdir readdirplus
> 0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
> fsstat fsinfo pathconf commit
> 0 0% 0 0% 0 0% 0 0%
>
>
>
> On Monday 18 Aug 2003 17:38, Lee wrote:
> > hmm, I'd check nfs version on both client and server, portmapper too,
> > and rpc stuff, check out some info form nfsstat too, that can shed light
> > on problem, netstat -s , is that giving you any info too??
> >
> > I'd check the nfs server , c if it's choking on something???
> >
> > Laters,
> > Lee
> >
> > On Mon, 2003-08-18 at 17:42, Iain Lennon wrote:
> > > All transfers are truncated at 1081344 bytes in length: just an
> > > observation The mount is under NFS.
> > >
> > > It seems to be an upload only problem (I've now noted the same thing from
> > > my laptop to the server over a PCMCIA wireless link)
> > > The devices involved are PCMCIA (ZoomAir 4105) on server and laptop and
> > > USB (Belkin F5D6050) on my office machine
> > >
> > >
> > > Drivers are wlan-ng 0.2.0-pre10 for the zoom card, and the ATMEL driver
> > > for the belkin
> > > Can't see any untoward activity in /var/log/syslog on either client or
> > > server side
> > >
> > > iwconfig reports signal level 17 and link quality 100 on the ATMEL
> > > device. wireless-tools are not theat reliable with wlan-ng so I haven't
> > > installed them!
> > >
> > > ssh transfers (using gftp as client) and transfers over to the samba
> > > server are not curtailed in any way. (for my sins I run win4lin on my
> > > office box, which accesses the server via samba: a 7mb transfer worked
> > > well)
> > >
> > > It seems like a protocol thing.
> > > I'm off to see if I can replicate this in Gnome, but hope this extra info
> > > helps
> > >
> > > Iain
> > >
> > > On Monday 18 Aug 2003 16:59, Lee wrote:
> > > > are you getting any other errorlog output, from samba/nfs
> > > >
> > > > is that mount an nfs mount, or samba mount or something else??
> > > >
> > > > check out /var/log/* or dmesg..have a snoop around, i dunno where the
> > > > kde shell sticks it output , if you run an instance of the file
> > > > explorer from an xterm, you might seem some extended error reporting?
> > > >
> > > > do you have any per use quota's enabled?
> > > >
> > > > post your error logs here..might shed some light on the subject.
> > > >
> > > > what kind of usb device are you using, I'd like to know?
> > > >
> > > > what's you signal strength like, and do you have a good connection to
> > > > your access point?
> > > >
> > > > Laters,
> > > > Lee
> > > >
> > > > On Mon, 2003-08-18 at 09:56, Iain Lennon wrote:
> > > > > Hi,
> > > > > I've noticed a problem with file copying in KDE which I think is
> > > > > probably due to my wireless network, but I'm looking for confirmation
> > > > > before I hit the mailing lists again.
> > > > >
> > > > > I'm using Mandrake 9.1
> > > > > My workhorse computer has a bekin wireless USB device, detected by
> > > > > the kernel, and with the help of a bash script in rc.d configures on
> > > > > boot up to talk to my server using a prism2 based PCMCIA card.
> > > > >
> > > > > Copying files of more than approx .5 Mb using KDE leads to an error
> > > > > "could not write to /mnt/multimedia/file...." with cancel / skip
> > > > > /autoskip options.
> > > > >
> > > > > However, so long as the file is less than 1mb pressing skip / auto
> > > > > skip will see the file written. If it is greater than 1MB its
> > > > > truncated.
> > > > >
> > > > > Sending the file via gftp to the server using ssh is trouble free.
> > > > > Downloading files using KDE works without error
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > --
> > > > > Iain Lennon
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Nottingham mailing list
> > > > > Nottingham@mailman.lug.org.uk
> > > > > http://mailman.lug.org.uk/mailman/listinfo/nottingham
> > > >
> > > > _______________________________________________
> > > > Nottingham mailing list
> > > > Nottingham@mailman.lug.org.uk
> > > > http://mailman.lug.org.uk/mailman/listinfo/nottingham
> > > >
> > > > _______________________________________________________________________
> > > >_ This email has been scanned using the CleanPort MEF antivirus
> > > > system. Funded for members by the Doctors.net.uk Bulletin service
> > > > How does this protect me? http://www.Doctors.net.uk/qualityemail
> > > > _______________________________________________________________________
> > > >_
> > >
> > > --
> > > Iain Lennon
> > > SpR Emergency Medicine
> > > Mid Trent Rotation
> > >
> > > _______________________________________________
> > > Nottingham mailing list
> > > Nottingham@mailman.lug.org.uk
> > > http://mailman.lug.org.uk/mailman/listinfo/nottingham
> >
> > _______________________________________________
> > Nottingham mailing list
> > Nottingham@mailman.lug.org.uk
> > http://mailman.lug.org.uk/mailman/listinfo/nottingham
> >
> > ________________________________________________________________________
> > This email has been scanned using the CleanPort MEF antivirus
> > system. Funded for members by the Doctors.net.uk Bulletin service
> > How does this protect me? http://www.Doctors.net.uk/qualityemail
> > ________________________________________________________________________
>
> --
> Iain Lennon
> SpR Emergency Medicine
> Mid Trent Rotation
>
> _______________________________________________
> Nottingham mailing list
> Nottingham@mailman.lug.org.uk
> http://mailman.lug.org.uk/mailman/listinfo/nottingham