SCO updates required for SAMBA 2.2.5 & 5.04
Jim Rendant
5MB files take over 20 minutes to open. As you see, this type of performance
can not continue.
Has anyone seen such poor performance?
FTP works great which leads me to believ that SAMBA is mis-configured.
However
when I loaded Visionfs I received the same disstressing results.
My environement is purley Windows 98 clients accessing the OpenServer 5.04
server with SAMBA 2.2.5. The Server is acting as the PDC with clients
logging
into the server.
In the textdocs directory of SAMBA it is mentioned to load uod385a, but
after
reading the attached letter it does not sound like it applies to Openserver
5.04.
I currently believe the client has the 5.04c patch installed but thats it.
Are there
other patches that should be installed?
After searching GOOGLE for slow excel files I was returned over 32,400 hits.
Most saying that Excel files are getting corrupted. Have you seen this?
If you are not suffering from any performance issues and you are using
SAMBA,
what locking methods are you using? Are you using READ/WRITE RAW?
What share modes are you using?
Please help me regain my sanity.....
Thanks
Jim Rendant
Steve Fabac
>
> I am having SEVERE problems with Samba ans/or visionfs with Excel files.
> 5MB files take over 20 minutes to open. As you see, this type of performance
> can not continue.
>
> Has anyone seen such poor performance?
> FTP works great which leads me to believ that SAMBA is mis-configured.
> However
> when I loaded Visionfs I received the same disstressing results.
>
> My environement is purley Windows 98 clients accessing the OpenServer 5.04
> server with SAMBA 2.2.5. The Server is acting as the PDC with clients
> logging
> into the server.
>
> In the textdocs directory of SAMBA it is mentioned to load uod385a, but
> after
> reading the attached letter it does not sound like it applies to Openserver
> 5.04.
>
> I currently believe the client has the 5.04c patch installed but thats it.
> Are there
> other patches that should be installed?
>
> After searching GOOGLE for slow excel files I was returned over 32,400 hits.
> Most saying that Excel files are getting corrupted. Have you seen this?
Sounds like you have Outlook or Outlook express installed and miss configured
to enable Journaling. Check your configuration and disable Journaling
and you should see an improvement in Excel.
I like to check data transfer by using the Windows Copy/Paste function
to copy the Netscape 4.7 installation archive (~19M) from VisionFS share
to local hard drive and back to different VisionFS share, With 10/100
switch and 3COM 3C905c NIC's I normally get 3 seconds for 19M.
>
> If you are not suffering from any performance issues and you are using
> SAMBA,
> what locking methods are you using? Are you using READ/WRITE RAW?
> What share modes are you using?
>
> Please help me regain my sanity.....
>
> Thanks
> Jim Rendant
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
Jim Rendant
Outlook is on there systems and there is no journaling turned on
Steve Fabac <smf...@att.net> wrote in message
news:3EDB2BB4...@att.net...
r000t
Steve Fabac
>
> No journaling at all is active.
> Outlook is on there systems and there is no journaling turned on
Check: 1) All win98 pc's running Excel are slow to load this file?
2) Copy the file to local hard drive then open it in Excel. Did it
take as long to load?
3) how long does it take to copy/paste the 5M file from UNIX server to
local hard drive.
4) Change name of file on local hard drive and copy it back to UNIX,
How long did that copy take?
Jeff Liebermann
wrote:
>I am having SEVERE problems with Samba ans/or visionfs with Excel files.
>5MB files take over 20 minutes to open. As you see, this type of performance
>can not continue.
Divide and conquer. Try an ftp file transfer between the OSR5 box and
the Windoze box. Do it in both directions and time how long it takes.
That takes SAMBA out of the picture. If the transfer time is
reasonable, then figure out what's wrong with SAMBA. Go to the SCO
"Knowledge Center" and inscribe "samba" in the search thing. There's
quite a bit on installation under TA114822 and 119726
My guess is that there's something busted on the network. netstat
should show some kind of errors.
Oh-oh. Re-reading the above quote, you say you're having trouble with
"Samba and/or visionfs". I hope you don't have *BOTH* Visionfs and
SAMBA installed simultaneously. You can't do that as they both use IP
port 137 and will not co-exist on the same machine.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
je...@comix.santa-cruz.ca.us je...@cruzio.com
Jim Rendant
I have run nestat -i, -s, and a timed output and I am including the results.
All the ICMP packects fail. 141 total
There is an interface atl0* which (nestat -i) returns as not being
configured.
from the TCP portion of netstat -s, I can see some retansmission but I don't
think
it is that bad
38 data packets (36824 bytes) retransmitted
1835 ack-only packets (130 delayed)
0 URG only packets
0 window probe packets
4 window update packets
317 control packets
44 resets
18519 packets received
15187 acks (for 7905296 bytes)
273 duplicate acks
The machine is a Compaq Proliant server running OpenServer 5.04c and a
Netflex3 card
installed. There are only about 15 users on this system.
netstat -s
ip:
19818 total packets received
0 bad header checksums
0 with bad IP version number
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with unknown protocol
0 with link layer broadcast addr but unicast IP addr
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets reassembled
0 packets forwarded
0 packets not forwardable
0 no routes
0 redirects sent
0 system errors during input
19818 packets delivered
21184 total packets sent
0 system errors during output
0 packets fragmented
0 packets not fragmentable
0 fragments created
0 PCBs failed connect due to bad source address
icmp:
141 calls to icmp_error
0 errors not generated because old message was icmp
Output histogram:
echo reply: 4
destination unreachable: 141
echo: 4
0 messages with bad code fields
0 messages < minimum length
0 bad checksums
0 messages with bad length
0 bad netmasks received
Input histogram:
echo reply: 4
echo: 4
4 message responses generated
8 messages received
149 messages sent
0 messages not sent due to bad source address
0 system errors during output
igmp:
0 messages received
0 messages received with too few bytes
0 messages received with bad checksum
0 membership queries received
0 membership queries received with invalid field(s)
0 membership reports received
0 membership reports received with invalid field(s)
0 membership reports received for groups to which we belong
0 membership reports sent
0 total packets sent
0 output errors
tcp:
20268 packets sent
20268 packets used fast path
18074 data packets (7906825 bytes)
38 data packets (36824 bytes) retransmitted
1835 ack-only packets (130 delayed)
0 URG only packets
0 window probe packets
4 window update packets
317 control packets
44 resets
18519 packets received
15187 acks (for 7905296 bytes)
273 duplicate acks
0 acks for unsent data
6510 packets (119692 bytes) received in-sequence
0 completely duplicate packets (0 bytes)
1 packet with some dup. data (0 bytes duped)
0 out-of-order packets (0 bytes)
0 packets (0 bytes) of data after window
0 window probes
0 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 system errors encountered during processing
38 connection requests
288 connection accepts
307 connections established (including accepts)
657 connections closed (including 1 drop)
19 embryonic connections dropped
0 failed connect and accept requests
1 reset received while established
15126 segments updated rtt (of 15152 attempts)
36 retransmit timeouts
0 connections dropped by rexmit timeout
1 persist timeout
1 alloc failure caused reschedule
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
2687 segments predicted
1640 acks predicted
udp:
0 incomplete headers
0 bad data length fields
0 bad checksums
231 bad ports (90 were broadcast/multicast)
339 input packets delivered
0 system errors during input
728 packets sent
0 streams allocation failures
# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
net0 1500 192.168.1 united1 20156 0 21440 4 0
lo0 8232 loopback localhost 498 0 498 0 0
atl0* 8232 none none No Statistics Available
# netstat -w 120
input (net0) output input (Total) output
packets errs packets errs colls packets errs packets errs
colls
20480 0 21745 4 0 21476 0 22741 4
0
500 0 469 0 0 500 0 469 0
0
650 0 593 0 0 650 0 593 0
0
437 0 397 0 0 437 0 397 0
0
647 0 581 0 0 647 0 581 0
0
762 0 691 0 0 762 0 691 0
0
759 0 667 0 0 759 0 667 0
0
724 0 650 0 0 724 0 650 0
0
146 0 169 0 0 146 0 169 0
0
474 0 414 0 0 474 0 414 0
0
599 0 544 0 0 599 0 544 0
0
1025 0 899 0 0 1025 0 899 0
0
900 0 769 0 0 900 0 769 0
0
803 0 707 0 0 803 0 707 0
0
589 0 530 0 0 589 0 530 0
0
385 0 360 0 0 385 0 360 0
0
717 0 612 0 0 717 0 612 0
0
1272 0 1108 0 0 1272 0 1108 0
0
506 0 439 0 0 506 0 439 0
0
967 0 832 0 0 967 0 832 0
0
1052 0 950 2 0 1052 0 950 2
0
input (net0) output input (Total) output
packets errs packets errs colls packets errs packets errs
colls
34876 0 34549 6 0 482 0 423 0
0
Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message
news:urfpdv016dcr5pjaj...@4ax.com...
Jeff Liebermann
wrote:
>FTP is blazingly fast
In both directions?
>> Oh-oh. Re-reading the above quote, you say you're having trouble with
>> "Samba and/or visionfs". I hope you don't have *BOTH* Visionfs and
>> SAMBA installed simultaneously. You can't do that as they both use IP
>> port 137 and will not co-exist on the same machine.
Do you happen to have both Samba and VisionFS installed on this
machine?
I had one Samba box running at the speed of a snail by confusing
NETBIOS. I had bogus entries in LMHOSTS and HOSTS on the Windoze
side, and different IP's in /etc/hosts that disagreed with the DNS
server. The Windoze box would try to re-open the connection to the
bogus IP's and Netbios names and stall large file tranfers. It also
showed up in very slow opens of shares on the Samba server.
Try this on the Windoze box. Open an MSDOS window and run:
net view
It should take about 5-20 seconds depending on the size of your
network. If it takes forever or longer than reasonable, then look for
confusion in the various name resolution mechanisms (WINS, DNS, hosts,
LMHOSTS, AD, LDAP, etc).
If that works, open the "Run" box on the Windoze machine and inscribe:
\\192.168.111.111 (the IP address of the Samba server).
It should instantly open a desktop explorer window showing all the
shares on the Samba server.
Now, do it again using the netbios name of the Samba server.
\\samba-netbios-name
If that takes forever but using the IP address is instantaneous, you
have a mess somewhere between HOSTS and LMHOSTS probably on the
Windoze side.