ET>>> 9 lazy write workers? I haven't seen mentioned that high before.

HR>> Why not?

 ET> I haven't seen that before.

No wounder. This parameter exists since FP5 or so and is nearly undocumented.
You have to read the readmes of your fixpacks carefully to find that.

HR>> The optimasion was done at a time this computer was used as - 3
HR>> lines node with mostly ISDN throughput - developement mashine
HR>> (edit/compile/debug...) with all lines running - some other
HR>> aktive tasks

 ET> so that number of lazy write workers maximize the write
 ET> performance to disk with a lowest possible CPU usage, so
 ET> maximizing transfer speed?

Yes.

HR>> I'd found that throwing on the cache parameters has the most
HR>> incredible effect on the transfer rates. I'd found values that are
HR>> commonly nearst the physical maximum (7950/15500 cps as sender and
HR>> 7850/14500 as receiver of *.bmp)

HR>> Exchange of large *.bmp can kill the telko's convey station if
HR>> both sides can send with maximum speed on direct CAPI. :-)

 ET> Don't tell your telco (Deutsche Telekom) that, or they will limit
 ET> the highest possible transfer speed to 7000 cps. ;-)

No. They do often switch off theyr stations fridays at 16.30h (end of work)
for the whole weekend and if you would them running you have to pay an extra
charge for to do so. Because they havend done that and its you fault that you
can't phone. Sometimes (in the evening - end of work by telko) you can call
out - but not called or you can't call out but called.........) Always it's
YOUR fault, never the telko's)

So if you can - you MUST try to reset the station to hold state. Sending a lot 
of constat 0 or 1 (a *.bmp is a file of that kind) is the most perfect way to
do so. :-)

 ET> I am just looking for more information about the number of lazy
 ET> write workers.

Good. You'll see most effect if you have only 16 MB RAM and the maximum cache
size (on HPFS 2MB). 


--- Sqed/32 1.15/development  301:
138/2