Silly reads from WinXP/OfficeXP against Samba 3.0

[Oktay Akbal]

According to MS-Knowledgebase artikel 322345 there is a confirmed Problem
with Word reading from UNC-Paths (which is not the Problem in the
described Case). What is really funny is, that they say, that the largest
CacheSize is 1024. I will retest this.

Oktay

On Wed, 16 Jul 2003, Oktay Akbal wrote:

> This does indeed work around the problem. At least what when we talk about
> performance on editing the file. But I still think, that a bit to much
> network traffic is caused (not that high as before).
>
> At least with samba3.0 and one specific Test-Document, setting CacheSize
> to 2048 or higher works. 512 or 1024 not. THis might be because the
> Test Doc is about 2.5Mb.
>
> And of course this has not been seen against WinNt4- or W2k-Servers.
> I read about "rabbit-pellet", but I assume that noone has further hints
> on how this is caused on non-Win-Servers ?
>
> Oktay
>
> > Hi,
> > 	While it's not quite the same as your environment, we saw very
> > similar behaviour, so maybe this will help.
> >
> > We had:
> > Windows 2000,
> > Word 2000, with "track changes" on.
> > Rational Reqpro (forget version). - which integrates word documents with
> > an SQL DB for project requirements management.
> >
> > Particularly when scrolling through the document, word would go insane
> > with <512 byte reads - as far as I can tell, the track changes mode
> > means the word document has it's content split all over the file, so
> > word has to keep jumping around all over the place. This is made worse
> > by the fact that by default, word only buffers about 64K of the file in
> > memory, and scrolling meant we "jumped out" of that buffer constantly.
> >
> > On a windows<->system, this behaviour is hidden by oplock caching.
> > However, word had a habit of opening the document 2 or 3 times, which
> > causes samba to break the oplock. I assume windows has some magic to
> > detect this behaviour, and keep the client cache valid.
> >
> > We worked around the problem with a registry hack to cause word to
> > buffer more of the document at a time:
> >
> > [HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Word\Options]
> > "CacheSize"="512"
> >
> > There's probably a similar option for XP.
> >
> > Cheers,
> > 	T.
> >
> > > -----Original Message-----
> > > From: Volker Lendecke [mailto:Volker.Lendecke at SerNet.DE]
> > > Sent: Wednesday, July 16, 2003 12:28 AM
> > > To: samba-technical at samba.org
> > > Subject: Silly reads from WinXP/OfficeXP against Samba 3.0
> > >
> > >
> > > Hi!
> > >
> > > Here I have a repeatable case: Office XP SP2 on WinXP reads a
> > > file, and
> > > during the first requests everything looks fine. Then after some time
> > > the machine starts to read *HUGE* amounts of 512
> > > byte-fragments from the
> > > .doc-file. This results in ~140000 packets whereas the same operations
> > > only use ~4000 packets when the file is on 2k.
> > >
> > > I already tried 'max xmit = 4356' to match 2k buffer size negotiation,
> > > but that did not help. One thing that I also found is that the client
> > > seems to actively use the multi-request feature of 2k.
> > >
> > > I can provide sniffs and tests with a patched Samba, but I'm
> > > currently a
> > > bit lost. Staring at a dump of 140000 packets is not exacly easy :-(
> > >
> > > Any idea anybody?
> > >
> > > Volker
> > >
> >
> >