Hi,
I have one old spare PC, a PIII with 128 MB RAM, that I use as a spare file server. I have a headless CentOS 5 install on it, and a 2 terabyte external USB harddisk. The machine is in my basement (because it's quite loud), and I'm using what's called "CPL" here (Courant Porteur), which is basically Ethernet over 220V power lines. It's much slower than normally cabled Ethernet, but it works OK.
I setup an NFS server on this machine, with the big 2TB storage on the external disk. On the first floor, on my main PC, I setup a consistent mounting of the NFS shares in /etc/fstab, and it works.
Now here's the problem. Some of the files are quite big, usually movie files that can make up to 4 GB. More often than not, when I cut/paste such a file from my local harddisk to the server, it's quite slow (understandably, due to the slow CPL connection), but then the operation freezes in the middle, the cursor is unresponsive, even [Ctrl+Alt+Backspace] doesn't work, and I have to do a hard reboot.
Now I wonder what this phenomenon can be due to. Some strange bottleneck effect due to either lack of RAM to the server or the slow network or both?
Any ideas?
Niki
On Tue, 2010-03-30 at 12:27 +0200, Niki Kovacs wrote:
Hi,
I have one old spare PC, a PIII with 128 MB RAM, that I use as a spare file server. I have a headless CentOS 5 install on it, and a 2 terabyte external USB harddisk.
--- This may help help you I have the same problem.
First to rule out the USB Drive copy file on the server machine itself from like a dvd rom to the USB Drive in order to check out how it is working,
Try this go directly to the Mount Folder of your NFS Share and open it up then copy and paste a file into it. Don't do a browse network to access the nfs share. You want the hard mounted nfs share.
You should have better success with another 128MB of RAM..
Case point I have one also a P3 450 256MB RAM CentOS 5.4 here at home using samba + clam av and large files make me have to hard mount the directory to paste to the server. I run no GUI either on it so you may want to get rid of X and Gnome. Mine I run in, run level 3 so no gui here because it was painfully slow.
John
JohnS a écrit :
This may help help you I have the same problem.
First to rule out the USB Drive copy file on the server machine itself from like a dvd rom to the USB Drive in order to check out how it is working,
Try this go directly to the Mount Folder of your NFS Share and open it up then copy and paste a file into it. Don't do a browse network to access the nfs share. You want the hard mounted nfs share.
You should have better success with another 128MB of RAM..
I *think* I found out. This same server also runs a cronjob for an rsync-based backup script, and it looks like after renaming some of the target directories that had to be filtered out, the script slowly but steadily filled the disk and then went rogue.
I corrected that problem, and now it *looks* like everything's OK. But you're right. Another 128 MB RAM won't hurt. (My first computer, a single-board 8080, actually had 512 *bytes* of RAM, so it's just a matter of adapting to modern times :oD)
Cheers,
Niki
On 3/30/2010 1:21 PM, Niki Kovacs wrote:
JohnS a écrit :
This may help help you I have the same problem.
First to rule out the USB Drive copy file on the server machine itself from like a dvd rom to the USB Drive in order to check out how it is working,
Try this go directly to the Mount Folder of your NFS Share and open it up then copy and paste a file into it. Don't do a browse network to access the nfs share. You want the hard mounted nfs share.
You should have better success with another 128MB of RAM..
I *think* I found out. This same server also runs a cronjob for an rsync-based backup script, and it looks like after renaming some of the target directories that had to be filtered out, the script slowly but steadily filled the disk and then went rogue.
I corrected that problem, and now it *looks* like everything's OK. But you're right. Another 128 MB RAM won't hurt. (My first computer, a single-board 8080, actually had 512 *bytes* of RAM, so it's just a matter of adapting to modern times :oD)
I think the trick is to spend as much _money_ as you did for RAM in the old days and you'll be fine.
Niki wrote:
JohnS a écrit :
<snip>
You should have better success with another 128MB of RAM..
<snip>
I corrected that problem, and now it *looks* like everything's OK. But you're right. Another 128 MB RAM won't hurt. (My first computer, a single-board 8080, actually had 512 *bytes* of RAM, so it's just a matter of adapting to modern times :oD)
*heh* I remember the first computer I owned, and my ex and a friend violated the warranty on the RadShack CoCo, opened it up, and doubled the memory for a birthday present. Then, I had 32K ram! (Are you sure you didn't mean 512K RAM?)
mark
m.roth@5-cent.us wrote:
Niki wrote:
JohnS a écrit :
<snip> >> You should have better success with another 128MB of RAM.. <snip> > I corrected that problem, and now it *looks* like everything's OK. But > you're right. Another 128 MB RAM won't hurt. (My first computer, a > single-board 8080, actually had 512 *bytes* of RAM, so it's just a > matter of adapting to modern times :oD)
*heh* I remember the first computer I owned, and my ex and a friend violated the warranty on the RadShack CoCo, opened it up, and doubled the memory for a birthday present. Then, I had 32K ram! (Are you sure you didn't mean 512K RAM?)
Not unless it had some additional hardware assistance. The 8080 can only address 64K.
Bob McConnell N2SPP
m.roth@5-cent.us wrote:
Niki wrote:
JohnS a écrit :
<snip> >> You should have better success with another 128MB of RAM.. <snip> > I corrected that problem, and now it *looks* like everything's OK. But > you're right. Another 128 MB RAM won't hurt. (My first computer, a > single-board 8080, actually had 512 *bytes* of RAM, so it's just a > matter of adapting to modern times :oD)
*heh* I remember the first computer I owned, and my ex and a friend violated the warranty on the RadShack CoCo, opened it up, and doubled the memory for a birthday present. Then, I had 32K ram! (Are you sure you didn't mean 512K RAM?)
Not unless it had some additional hardware assistance. The 8080 can only address 64K.
Apologies - I was thinking 8088. Name doesn't sound at *all* alike.... <g>
mark
On Tue, Mar 30, 2010 at 4:52 PM, Bob McConnell rmcconne@lightlink.com wrote: dn't mean 512K RAM?)
Not unless it had some additional hardware assistance. The 8080 can only address 64K.
:D
I remember some 6502-based systems that used bank switching to access separate 32K windows... Used it mainly for RAM disks.. Was pretty impressive to see apps load within a second when 1 to 2 minutes was the usual wait time.
On Wed, Mar 31, 2010 at 04:21:32AM -0400, Kwan Lowe wrote:
I remember some 6502-based systems that used bank switching to access separate 32K windows... Used it mainly for RAM disks.. Was pretty impressive to see apps load within a second when 1 to 2 minutes was the usual wait time.
The BBC Microcomputer (2Mhz 6502) from the early 80s came with 32Kb RAM, 32Kb ROM (16Kb OS ROM, 16Kb paged ROM, for language etc). RAM 0->0x7fff, Paged ROM (aka "Sideways ROM - SWR") 0x8000->0xbfff, OS ROM 0xc000->0xffff.
The language ROM idea was quite clever; it came with BASIC but you could install 3 other ROMS (or with an expansion board, 15 other ROMS) in there and so could have Pascal or a wordprocessor or an interactive assember/debugger or...
So then some clever person thought "what if I put RAM in there". The first use was to be able to load ROM images into it, so effectively letting you change the language ROMs you wanted to use. But with some bank switching it was possible to create a RAMdisk (the BBC was well designed for this sort of expansion). 128Kbyte RAMdisks used 8 of the SWR banks, typically on a expansion daughter board. Since floppy disks at the time ran from 100Kbyte (40track single sided single density) to 720Kbyte (80track double sided double density), a 128Kbyte RAMdisk was nothing to be sneezed at.
Next step was "shadow memory". The BBCs designed shared the program memory with the screen memory. The highest resolution was 20Kb in size (which ran from top of RAM down). Add in OS overheads (3.75Kb) and you didn't have much space for programming! So another form of paging was used to help here; the OS write-character routines were intercepted and banks were switched so the pixels were drawn and then the banks switched back. From a well-written programs perspective this was transparent. A little slow, but it worked :-)
That was a fun machine to use!
Bob McConnell wrote:
Not unless it had some additional hardware assistance. The 8080 can only address 64K.
indeed. There were exceptions, but yes, this involved 'additional hardware assistance' in the form of bank switching, or bank mapping. Altos Computers and others made Z80 systems which had 4 or more banks of 64K memory minus a small chunk of shared memory, these ran the multiuser CP/M known as MP/M-80... IIRC, this was circa 1979 or 1980.
m.roth@5-cent.us a écrit :
*heh* I remember the first computer I owned, and my ex and a friend violated the warranty on the RadShack CoCo, opened it up, and doubled the memory for a birthday present. Then, I had 32K ram! (Are you sure you didn't mean 512K RAM?)
No, 512 Byte. Here's one similar :
http://www.computermuseum-mannheim.de/images/pic_g/siemens_8080_1g.jpg
The thing had to be programmed in Assembler using a hex keyboard.
My dad worked at a lab at Siemens and brought one of these things home, along with my first two computer books : "Binäre Algebra" and "Logische Schaltkreise" (logical circuits). My first program were flowcharts on paper that I had to convert to hex code and poke into the computer.
Folks who say the Linux command line isn't comfortable don't know what they're talking about :o)
Greetings,
On Wed, Mar 31, 2010 at 3:29 AM, Niki Kovacs contact@kikinovak.net wrote:
m.roth@5-cent.us a écrit : Folks who say the Linux command line isn't comfortable don't know what they're talking about :o)
Very true.
My first was 8085 board with hex keypad.
next was z80 with CP/M OS..
Regards,
Rajagopal
On Tue, 2010-03-30 at 23:59 +0200, Niki Kovacs wrote:
No, 512 Byte. Here's one similar :
http://www.computermuseum-mannheim.de/images/pic_g/siemens_8080_1g.jpg
The thing had to be programmed in Assembler using a hex keyboard.
My dad worked at a lab at Siemens and brought one of these things home, along with my first two computer books : "Binäre Algebra" and "Logische Schaltkreise" (logical circuits). My first program were flowcharts on paper that I had to convert to hex code and poke into the computer.
Folks who say the Linux command line isn't comfortable don't know what they're talking about :o)
--- You should be really punch board literate then :-) So tell him now you need the Digital Circuits book now.
John
JohnS a écrit :
You should have better success with another 128MB of RAM..
Case point I have one also a P3 450 256MB RAM CentOS 5.4 here at home using samba + clam av and large files make me have to hard mount the directory to paste to the server. I run no GUI either on it so you may want to get rid of X and Gnome. Mine I run in, run level 3 so no gui here because it was painfully slow.
I had some time this weekend to check this out. I found another 128 MB RAM, put it into the server (and tested it OK). I took the server to my office and connected it directly to the main switch, to rule out networking bottlenecks.
I opened up 'top' on the server and switched to memory display (Shift-O, O, Enter).
On my desktop PC I transferred a bunch of files, and memory usage instantly went from around 110 MB to 250 MB, and then it began to swap and left the transfer with a steady 4800 k/s stream.
So I guess it was effectively a problem of missing RAM.
Cheers,
Niki
PS : machine is also running dhcpd, named, httpd, mysqld, squid, smb, and I feel like I'm moving an appartment in a Morris Mini Cooper :o)
On Sat, 2010-04-03 at 17:22 +0200, Niki Kovacs wrote:
JohnS a écrit :
You should have better success with another 128MB of RAM..
Case point I have one also a P3 450 256MB RAM CentOS 5.4 here at home using samba + clam av and large files make me have to hard mount the directory to paste to the server. I run no GUI either on it so you may want to get rid of X and Gnome. Mine I run in, run level 3 so no gui here because it was painfully slow.
I had some time this weekend to check this out. I found another 128 MB RAM, put it into the server (and tested it OK). I took the server to my office and connected it directly to the main switch, to rule out networking bottlenecks.
I opened up 'top' on the server and switched to memory display (Shift-O, O, Enter).
On my desktop PC I transferred a bunch of files, and memory usage instantly went from around 110 MB to 250 MB, and then it began to swap and left the transfer with a steady 4800 k/s stream.
So I guess it was effectively a problem of missing RAM.
Cheers,
Niki
--- Yea although CentOS 5 can be ran with 128 I promise you want be happy with it. I think in my initial post to you I neglected to include I have clamav-samba running also. All my media files I had to confiigure the cifs shares for clam-av to not scan them. i do come to find out I have a lil more than 256MB of ram but not by much. I do have every service I do not need cut off. Also mine swaps also. You should get better spped than what your getting. I can't get no more than 10MB/s. My smb global config may help some.
top - 08:12:13 up 13 days, 4:55, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 385356k total, 380516k used, 4840k free, 4372k buffers Swap: 655352k total, 68k used, 655284k free, 330532k cached
[global]
max xmit = 65535 disable netbios = yes socket options = TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=524288 \ SO_SNDBUF=524288 write raw = yes read raw = yes oplocks = no
John
-
Bob McConnell -
John R Pierce -
JohnS -
Kwan Lowe -
Les Mikesell -
m.roth＠5-cent.us -
Niki Kovacs -
Rajagopal Swaminathan -
Stephen Harris