Re: Re: ENBD and swap

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter T. Breuer wrote:
|>This concludes the discussion for me. The rest of this email isn't
|>important and can be skipped if you like.
|>
|>
|>>But why not "just do that"? I know what you want it for - why repeat?
|>
|>Sorry about that.
|
|
| Until you actually get a problem in that situation, it's hard to predict
| what problem you WILL get.
|
| If there is a problem, maybe it will come from running more than one
| client daemon at a time, thus allowing two requests to be "in flight"
| across tcp at a time, thus forcing increased tcp buffer use, thus
| triggering a possible deadlock of swap against tcp, when swap is over
| tcp.
|
| Well, try with only one daemon then .. or, if you are prepared to
| experiment, I can try allowing several daemons (for redundancy), but
| making them mutually exclusive of each other when working across the
| same tcp connection.
|
| Another problem may occur from letting requests to the daemon pileup
| in the kernel driver, before any of them can be treated at all.  Well,
| one at a time will be treated, and maybe that's OK.  Still, I could
| restrict kernel requests to "only one outstanding at a time". It would
| mean setting ones own make_request function, and extremely stupid one,
| that does none of that kernel elevator-function-aggregation thing.
|
| But unless someone actually locates a problem that has to be solved, I
| don't see why it should be tried.
|
|
|>>around them - use 1KB blocksize and good duplex cabling. A 100BT
|>>switch should take care of it.
|>
|>Fine for my own needs...
|>
|>What I'm trying to discuss is the direction of the main LTSP
|>development. Whether a 100 BT switch would take care of it is irrelevant
|>then - what matters is that any new LTSP version could be taken in use
|>in the hundreds of existing LTSP networks already out there (backwards
|>compatability).
|
|
| Yes, but tcp needs buffers. Buffers need memory. You need swap when you
| run out of memory. If swap is over tcp, we have a potential deadlock.
|
| Using some other protocol that tcp may be a good idea. Arne Wiebalck
| at least managed that other scsi protocol, what is it called, SCTP?
| The kernel has support for that:
|
|   "SCTP is a reliable transport protocol operating on top of a
|    connectionless packet network such as IP.  It offers the
|    following services to its users ...
|
| I must try it! I'm not sure how to bind a network socket to SCTP rather
| than TCP, but it sounds worthwhile. Arne may be able to ay more.
|
|
|>>There is no reason to use more than 32MB of memory!  I run my X
|>>terminal (a 486sx50) on 8MB.
|>
|>The experiences of LTSP users worldwide suggests otherwise (and I
|>personally had a client chrash about once a month until I enabled swap).
|
|
| :( I think once a month would be fine for normal use (heh, I crash my
| kernel every few days), but a crash will only be a userspace crash due to
| lack of memory, which will free up memory, allowing one to restart in
| userspace.  My 8MB buys me something like init, X (well 800x600 - it's
| an old laptop), a getty, inetd, and a couple more things I forget.  I
| start the window manager remotely, so all apps are started on the
| server, not the client.

Presumably, your 486 has swap allocated on disk space.  Those X clients
actually require memory on the 486 X server to display the widgets and
the icons and the background, etc. etc.  If you throw a Mozilla window
or an OpenOffice window at your client, I can almost guarantee that it
will be forced to swap in that situation.  32MB RAM is just barely not
enough to handle the above apps and a full blown desktop like KDE.  64MB
seems to be the sweet spot, and ~128MB you shouldn't run into any
problems whatsoever, of course based on how many windows you have open
and whether you are running any local applications on the thin client, etc.

- --
Jason A. Pattie
Systems Administrator
Object Computing, Inc.
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCTDACopP6r7cyAYYRAq/VAJ9mlcQhkjxwjQK4JVrRXr4Jjh8oTgCfcF9i
1G6HqKOPxgHGhpi7QV5OMYY=
=Dnov
-----END PGP SIGNATURE-----