From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 18 Mar 2002 04:19:51 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 167 ************************************************** Sunday 17 March 2002 Number 167 ************************************************** Subjects for today 1 Re: OS/2 v. Linux performance : Brian Smith" 2 Re: RAMIFS : Henry Sobotka 3 Re: OS/2 v. Linux performance : Holger Veit 4 RAMIFS : John Poltorak 5 Re: PINE mailbox format : Mentore Siesto 6 ISPELL v3.2.06 : John Poltorak 7 Re: RAMIFS : John Poltorak 8 Re: ISPELL v3.2.06 : Dave and Natalie" 9 Re: OS/2 v. Linux performance : Michael Taylor 10 Gnat 3.14p OS/2 gnat.adc file broken? : Kees de LezenneCoulander 11 SquidGuard : John Poltorak 12 Re: RAMIFS : Andrew Belov" 13 Re: RAMIFS : John Poltorak 14 Re: RAMIFS : Andrew Belov" 15 Re: Building XFree86 v3.3.6 : John Poltorak 16 Re: RAMIFS : Henry Sobotka 17 Re: OS/2 v. Linux performance : Michael Taylor 18 Re: Gnat 3.14p OS/2 gnat.adc file broken? : Vincent Marciante 19 Re: RAMIFS : Marty" 20 Re: ISPELL v3.2.06 : John Poltorak 21 Re: Building XFree86 v3.3.6 : Holger Veit **= Email 1 ==========================** Date: Mon, 18 Mar 2002 02:53:46 -0600 (CST) From: "Brian Smith" Subject: Re: OS/2 v. Linux performance On Mon, 18 Mar 2002 12:53:28 +1000, Michael Taylor wrote: >Dave and Natalie wrote: >> >> One thing that OS/2 may do much better then Linux is scale up. Once the CPU count gets larger then 8 I'd >> think OS/2 may very well outperform everything else on Intel. Imagine WSEB on a 64 cpu machine . >> Sure wish more benchmarks included OS/2 in their comparisions. >> I also think that OS/2 performs better under heavy load then most others. Linux gets pretty unuseable here if >> there is too much going on, OS/2 just gets slow. > >WIn2K almost stops :-( > >Try doing "cvs update" in one window and a compile in another. Both operations take 5 to 10 times >longer than if you run them one after another. I keep forgetting as until 6 months ago I was running >WSeB on my SMP box at work :-( On WSeB they took about the same time as running them one after the >other, >in some cases they were faster as both cpus were in use. > >Basically on Win2K if your tasks involve network use (the C compiler is on a file server and cvs >connects to a linux CVS server) then expect extreme degradation in performance. > >If I try to start Netscape whilst running cvs and the compiler it takes up to 10 minutes to start! I think you are exaggerating, while OS/2 definitely multitasks better than windows, 5 to 10 times is way too much. I build the same software on both OS/2 and Windows, and if I do multiple compiles simultaneously it does not increase compile times much at all... and certainly not a factor of 5 or more. I am certainly no fan of Windows but those statistics sound an awful lot like FUD to me. Unless of course you are using cygwin, in which case the figures might be true, but that isn't window's fault... it's cygwin's. Cygwin in my experience performs horribly, and even worse with multiple processes executing simultaneously. But using Visual C or Borland C I have never seen the degradation you are talking about. And I use cvs heavily as well (connecting to OS/2, Linux and FreeBSD cvs servers). Brian **= Email 2 ==========================** Date: Mon, 18 Mar 2002 09:26:18 -0500 From: Henry Sobotka Subject: Re: RAMIFS John Poltorak wrote: > > The source for RAMFS64 doesn't seem to be available and it isn't clear who wrote it. The srcs are in ramfs.zip and authorship details in the readme. I've found it capable of handling a mozilla build (240MB src + 160MB obj tree), which I would consider a fairly good stress test. h~ **= Email 3 ==========================** Date: Mon, 18 Mar 2002 10:00:56 +0100 From: Holger Veit Subject: Re: OS/2 v. Linux performance On Sun, Mar 17, 2002 at 10:07:05PM +0100, Adrian Gschwend wrote: > On Thu, 14 Mar 2002 14:58:55 +0100, Holger Veit wrote: > > >The paths to the system should be shorter, but the real improvement, as already > >mentioned will be achieveable through native threading rather than emulated fork. > > does that mean that instead of a "real" fork it creates a new thread > instead? Is that suposed to work? (don't know much about > multiprocessing/threading yet so sorry if this is a stupid question :-) I am still experimenting with this, so no final decision what can be done. What you describe is known in Unix as vfork(): create a thread and manipulate pid/tid for this thread in a way that the UnixOS/2 process believes it is a new process. This is definitely possible and leads to a very fast forking operation. In most cases - vfork was intended for the case that you create a new process slot and then immediately execv() a new real process executable - this is sufficient. The tricky thing is when an application uses fork() (or its brother clone()) to emulate threading (clone() is already known to cause problems as it modifies the pid, so a new "thread" will get a different process id). The problem with that kind of fork() is that it requires copy-on-write which means that an implementor will have to fiddle with process page tables. This is particularly tricky when SMP comes into play. EMX circumvents this effect by implementing a "classical" fork() that simply copies real data of the data/stack/heap segments to the forked process. This is an extremely slow operation. Manipulating PDE/PTEs is extremely fast, in contrast, but relies on a COW in the kernel (there should be one, otherwise one cannot implement non-shared data segments in DLLs efficiently). There are some variants, e.g. rfork() which allows to select which parts of the parent process are to be copied (e.g. file handles), but this is then just implementation detail, once the real COW fork() is done (and particularly file handles are preety simple to clone, as they are located in a well-accessible part of the PTDA area of a process). Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 4 ==========================** Date: Mon, 18 Mar 2002 10:11:09 +0000 From: John Poltorak Subject: RAMIFS On Sun, Mar 17, 2002 at 02:19:58PM -0500, Marty wrote: > On a side note, I just booted up with eCS FP2. I'd post this to the eCS server, but > I can't get to it for some reason. Whatever you do, DON'T use a RAMIFS drive as a > temp drive when doing the fixpack installation. After FSERVICE runs, any access to > the RAMIFS drive will lock the system. I was able to change TEMP in my Config.Sys, > backout, and reapply the fixpack successfully, thank goodness. When I looked at using RAMIFS as a location for %TMP%, I was pretty disappointed with its performance. VDISK seemed much better but is restricted to FAT although if HPFS is required you could try SVDISK. Speaking of %TMP% raises the issue of /tmp and %UNIXROOT% under libemx... Will libemx allow for /tmp to be mounted on a VDISK? Will there be any option for mapping /tmp to %TMP%? -- John **= Email 5 ==========================** Date: Mon, 18 Mar 2002 10:16:48 +0100 (CET) From: Mentore Siesto Subject: Re: PINE mailbox format On Sat, 16 Mar 2002, Nicholas Sheppard wrote: NS >On Fri, 15 Mar 2002, John Poltorak wrote: NS > NS >> Are there any utils for being able to convert between different mail NS >> formats? NS > NS >There are several converters on Hobbes in /pub/os2/apps/internet/mail/util NS >but they look to me (on a quick look through the contents page) like they NS >only convert between various OS/2 mailer formats. Yes, there are no programs which convert from/to Pine format (which is an ASCII file containing all mail belonging to a certain mail folder). NS >> Is it possible to add new formats, such as that used by LaMail for NS >> instance? I'm just asking if this would involve much work. It _may_ be as NS >> simple as defining the structure of the mailbox, but probably not... AFAIK Pine has got only one mail file format, which is valid also for newsgroups. Or were you talking about some other mail client? NS >Mailbox format converters are probably a much better idea than making NS >e-mail clients that understand every format ever devised. I agree on this. -- Mentore Siesto Team OS/2 Italia (http://www.teamos2.it) Home page: http://www.geocities.com/mentoruccio/ **= Email 6 ==========================** Date: Mon, 18 Mar 2002 11:33:33 +0000 From: John Poltorak Subject: ISPELL v3.2.06 There is an OS/2 port of ISPELL v3.2.06 available here:- http://www.proxyma.ru/stream/bin/ispell3206r.zip If anyone is familiar with ISPELL can you check it out? I'd like to keep the UnixOS2 packages uptodate and this port seems current. For anyone interested in ISPELL, see the homepage here:- http://fmg-www.cs.ucla.edu/geoff/ispell.html -- John **= Email 7 ==========================** Date: Mon, 18 Mar 2002 12:25:31 +0000 From: John Poltorak Subject: Re: RAMIFS On Mon, Mar 18, 2002 at 02:52:20PM +0300, Andrew Belov wrote: > On Mon, 18 Mar 2002 10:11:09 +0000, John Poltorak wrote: > > >When I looked at using RAMIFS as a location for %TMP%, I was pretty > >disappointed with its performance. VDISK seemed much better but is > >restricted to FAT although if HPFS is required you could try SVDISK. > > It seems to be inefficient when the file is grown constantly in relatively small > increments. Looks like the common case of realloc() being {malloc(); memcpy(); > free()}. Wondering if it can be fixed - say, by implementing chained "clusters". > > RAMFS is otherwise perfect - I use RAMFS64 to run "heavy-duty" compiles (e.g. > customized build of Odin) and it never fails, being as fast as HPFS386 cache (1466 > MHz Athlon XP, 512M DDR RAM, 20G IBM DJNA HDD). The best thing about it is > that the RAM used by it is pertinent to individual files, and can be (1) swapped out, > or (2) reclaimed after deletion of files. Hmmm... I used RAMFS previously AFAICR, presumably RAMFS64 is an updated version... The source for RAMFS64 doesn't seem to be available and it isn't clear who wrote it. -- John **= Email 8 ==========================** Date: Mon, 18 Mar 2002 12:51:02 -0800 From: "Dave and Natalie" Subject: Re: ISPELL v3.2.06 On Mon, 18 Mar 2002 11:33:33 +0000, John Poltorak wrote: > >There is an OS/2 port of ISPELL v3.2.06 available here:- > >http://www.proxyma.ru/stream/bin/ispell3206r.zip > > >If anyone is familiar with ISPELL can you check it out? > >I'd like to keep the UnixOS2 packages uptodate and this port seems >current. I looked at this and I don't think it would be compatible with unix/os2. It seems to be compiled (vacc) to run in its own directory with lib under it and no english dictionary. The patches might be worth using in a recompile though. Dave **= Email 9 ==========================** Date: Mon, 18 Mar 2002 12:53:28 +1000 From: Michael Taylor Subject: Re: OS/2 v. Linux performance Dave and Natalie wrote: > > One thing that OS/2 may do much better then Linux is scale up. Once the CPU count gets larger then 8 I'd > think OS/2 may very well outperform everything else on Intel. Imagine WSEB on a 64 cpu machine . > Sure wish more benchmarks included OS/2 in their comparisions. > I also think that OS/2 performs better under heavy load then most others. Linux gets pretty unuseable here if > there is too much going on, OS/2 just gets slow. WIn2K almost stops :-( Try doing "cvs update" in one window and a compile in another. Both operations take 5 to 10 times longer than if you run them one after another. I keep forgetting as until 6 months ago I was running WSeB on my SMP box at work :-( On WSeB they took about the same time as running them one after the other, in some cases they were faster as both cpus were in use. Basically on Win2K if your tasks involve network use (the C compiler is on a file server and cvs connects to a linux CVS server) then expect extreme degradation in performance. If I try to start Netscape whilst running cvs and the compiler it takes up to 10 minutes to start! -- Regards, Mick -- ----------------------------------------------------------------------- Michael Taylor miket at pcug.org.au ----------------------------------------------------------------- Home Page: http://www.geocities.com/miket5au/ http://users.bigpond.net.au/miket5au ----------------------------------------------------------------- ----------------------------------------------------------------------- **= Email 10 ==========================** Date: Mon, 18 Mar 2002 14:10:16 -0500 From: Kees de LezenneCoulander Subject: Gnat 3.14p OS/2 gnat.adc file broken? Vincent Marciante wrote: >When I try having a gnat.adc file with Source_File_Name pragmas >(those actually ar the only pragmas that I've tried) in it, I >always get an error message. Has anyone tried using a gnat.adc >file? Vincent, I have never had a need for using gnat.adc, but I tried one this morning, and it seemed to work OK (using Gnat 3.14p for OS/2). If the problem has not yet solved itself, you are welcome to send me your gnat.adc (and any small files it may require) so that I can try it out on my system. Kees de Lezenne Coulander -- C.M. de Lezenne Coulander Aircraft Development and Systems Engineering B.V. Hoofddorp, The Netherlands **= Email 11 ==========================** Date: Mon, 18 Mar 2002 14:11:10 +0000 From: John Poltorak Subject: SquidGuard I'm just about to give SquidGuard v1.1.4 a try, although I see that v1.2.0 has now been released. Is there any chance of the OS/2 port being updated? -- John **= Email 12 ==========================** Date: Mon, 18 Mar 2002 14:52:20 +0300 (MSK) From: "Andrew Belov" Subject: Re: RAMIFS On Mon, 18 Mar 2002 10:11:09 +0000, John Poltorak wrote: >When I looked at using RAMIFS as a location for %TMP%, I was pretty >disappointed with its performance. VDISK seemed much better but is >restricted to FAT although if HPFS is required you could try SVDISK. It seems to be inefficient when the file is grown constantly in relatively small increments. Looks like the common case of realloc() being {malloc(); memcpy(); free()}. Wondering if it can be fixed - say, by implementing chained "clusters". RAMFS is otherwise perfect - I use RAMFS64 to run "heavy-duty" compiles (e.g. customized build of Odin) and it never fails, being as fast as HPFS386 cache (1466 MHz Athlon XP, 512M DDR RAM, 20G IBM DJNA HDD). The best thing about it is that the RAM used by it is pertinent to individual files, and can be (1) swapped out, or (2) reclaimed after deletion of files. **= Email 13 ==========================** Date: Mon, 18 Mar 2002 14:53:00 +0000 From: John Poltorak Subject: Re: RAMIFS On Mon, Mar 18, 2002 at 09:26:18AM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > The source for RAMFS64 doesn't seem to be available and it isn't clear who wrote it. > > The srcs are in ramfs.zip and authorship details in the readme. That's the source for RAMFS - it isn't clear (to me) what is the diffence between RAMFS and RAMFS64 and who made the changes, whatever they were. > I've > found it capable of handling a mozilla build (240MB src + 160MB obj > tree), which I would consider a fairly good stress test. If it handles mozilla, there shouldn't be problem with JOE, or is that because of changes in MCP2. Have you installed MCP2? > h~ -- John **= Email 14 ==========================** Date: Mon, 18 Mar 2002 15:50:16 +0300 (MSK) From: "Andrew Belov" Subject: Re: RAMIFS On Mon, 18 Mar 2002 12:25:31 +0000, John Poltorak wrote: >> RAMFS is otherwise perfect - I use RAMFS64 to run "heavy-duty" compiles (e.g. >> customized build of Odin) and it never fails, being as fast as HPFS386 cache (1466 >> MHz Athlon XP, 512M DDR RAM, 20G IBM DJNA HDD). The best thing about it is >> that the RAM used by it is pertinent to individual files, and can be (1) swapped out, >> or (2) reclaimed after deletion of files. > >Hmmm... I used RAMFS previously AFAICR, presumably RAMFS64 is an updated >version... The source for RAMFS64 doesn't seem to be available and it >isn't clear who wrote it. RAMFS64 is only different to RAMFS in that it has been patched to report 64M of free space instead of 1M - this hack prevents several programs from complaining about insufficient free space. **= Email 15 ==========================** Date: Mon, 18 Mar 2002 16:27:20 +0000 From: John Poltorak Subject: Re: Building XFree86 v3.3.6 On Tue, Mar 19, 2002 at 01:11:03AM +0900, Jun Sawataishi wrote: > At Sun, 17 Mar 2002 19:18:11 +0000, > John Poltorak wrote: > > I'm thinking of rebuilding XFree86 v3.3.6 and would be interested in > > anyone's experience of attempting this... > All you have to do is to read an instruction written by Hoger, > "xc/programs/Xserver/hw/xfree86/doc/OS2.Notes". > I have built XFree86 v3.3.1 to 3.3.6 successfully with no trouble. > > If you encounter a trouble, please e-mail me before write to > Holger. I got as far as Step 5 which says there should be a file added-XXX, but I didn't find anything.... Is there such a file in v3.3.6 ? > # OS/2 is not a question, it's a solution. > # SAWATAISHI Jun > # http://www2s.biglobe.ne.jp/~vtgf3mpr/ -- John **= Email 16 ==========================** Date: Mon, 18 Mar 2002 18:43:07 -0500 From: Henry Sobotka Subject: Re: RAMIFS John Poltorak wrote: > > That's the source for RAMFS - it isn't clear (to me) what is the > diffence between RAMFS and RAMFS64 and who made the changes, whatever they > were. The difference is clear: as AB pointed out, the new version returns 64MB instead of the 1MB as the amount of free space left. Whether Jack Stein or Eddy Thilleman made the change and rebuilt it is less clear. > If it handles mozilla, there shouldn't be problem with JOE, or is that > because of changes in MCP2. Have you installed MCP2? No, I'm running the CP from the DeveloperToolbox CDs. h~ **= Email 17 ==========================** Date: Mon, 18 Mar 2002 20:17:29 +1000 From: Michael Taylor Subject: Re: OS/2 v. Linux performance Brian Smith wrote: > > On Mon, 18 Mar 2002 12:53:28 +1000, Michael Taylor wrote: > > >Dave and Natalie wrote: > >> > >> One thing that OS/2 may do much better then Linux is scale up. Once the CPU count gets larger then 8 I'd > >> think OS/2 may very well outperform everything else on Intel. Imagine WSEB on a 64 cpu machine . > >> Sure wish more benchmarks included OS/2 in their comparisions. > >> I also think that OS/2 performs better under heavy load then most others. Linux gets pretty unuseable > here if > >> there is too much going on, OS/2 just gets slow. > > > >WIn2K almost stops :-( > > > >Try doing "cvs update" in one window and a compile in another. Both operations take 5 to 10 times > >longer than if you run them one after another. I keep forgetting as until 6 months ago I was running > >WSeB on my SMP box at work :-( On WSeB they took about the same time as running them one after the > >other, in some cases they were faster as both cpus were in use. > > > >Basically on Win2K if your tasks involve network use (the C compiler is on a file server and cvs > >connects to a linux CVS server) then expect extreme degradation in performance. > > > >If I try to start Netscape whilst running cvs and the compiler it takes up to 10 minutes to start! > > I think you are exaggerating, while OS/2 definitely multitasks better than windows, 5 to 10 times is way > too much. I build the same software on both OS/2 and Windows, and if I do multiple compiles simultaneously > it does not increase compile times much at all... and certainly not a factor of 5 or more. I am certainly > no fan of Windows but those statistics sound an awful lot like FUD to me. Believe what you like or come and see it in action. As I said I believe it is because of the network activity. I can only offer anecdotal evidence as it is based on one persons experience (mine). Everyone else in the office (I am the only one who used to use OS/2) waits for the compile to finish. The only thing any of them do is to switch back to their editor (or a telnet session). Nobody else would dream of doing what I do - they never try to start another task, they only use applications that were already running. And I have actually timed it. A two minute compile/link took over ten minutes whilst "cvs update" was running. I didn't believe it at first but I have repeated it many times. It is definitely not as bad when the C COmpiler is installed locally. > > Unless of course you are using cygwin, in which case the figures might be true, but that isn't window's > fault... it's cygwin's. Cygwin in my experience performs horribly, and even worse with multiple processes > executing simultaneously. But using Visual C or Borland C I have never seen the degradation you are > talking about. And I use cvs heavily as well (connecting to OS/2, Linux and FreeBSD cvs servers). We use Visual C. Latest version (or close to it - V6 with the latest fixpack that doesn't break anything). -- Regards, Mick -- ----------------------------------------------------------------------- Michael Taylor miket at pcug.org.au ----------------------------------------------------------------- Home Page: http://www.geocities.com/miket5au/ http://users.bigpond.net.au/miket5au ----------------------------------------------------------------- ----------------------------------------------------------------------- **= Email 18 ==========================** Date: Mon, 18 Mar 2002 20:24:53 -0500 From: Vincent Marciante Subject: Re: Gnat 3.14p OS/2 gnat.adc file broken? Kees de LezenneCoulander wrote: > > Vincent, > I have never had a need for using gnat.adc, but I tried one > this morning, and it seemed to work OK (using Gnat 3.14p for OS/2). > If the problem has not yet solved itself, you are welcome to send > me your gnat.adc (and any small files it may require) so that I can > try it out on my system. > Kees de Lezenne Coulander > -- > C.M. de Lezenne Coulander > Aircraft Development and Systems Engineering B.V. > Hoofddorp, The Netherlands > Kees, Thanks for confirming that using a gnat.adc works on your system. I'll first try to make sure that my configuration is not messed up in some way before I correspond further. By the way, I have been using gnat.adc's with GNAT 3.12p on Warp 4 with no fixpacks for a few years now so maybe I did a bad upgrade to 3.14p. I'll update my situation as it develops. Vinny **= Email 19 ==========================** Date: Mon, 18 Mar 2002 21:26:44 -0500 (EST) From: "Marty" Subject: Re: RAMIFS On Mon, 18 Mar 2002 14:53:00 +0000, John Poltorak wrote: > If it handles mozilla, there shouldn't be problem with JOE, or is that > because of changes in MCP2. Have you installed MCP2? Now you're mixing up my messages. :-) I said it had a problem with eCS FP2. Once FSERVICE finishes, it replaces something that destroys access to RAMFS. Any subsequent access to RAMFS after FSERVICE runs can make that process block forever (and leave it unkillable), throwing a big fat monkey-wrench into the fixpack installation process. RAMFS has worked well for me in all other areas. Heck... I used to copy my entire Fallout 2 CD to the RAM drive and run the game from there. Worked wonderfully well. I have noticed, however, that certain kinds of access to it cause the system to really slow to a crawl. Sequential reads or writes seem very fast, but whenever a large amount of seeking is involved within a given file, the overall system starts to slow down to a crawl, removing CPU service to user processes and hogging it in the kernel. I haven't tried it under straight Warp 4 for comparison. **= Email 20 ==========================** Date: Mon, 18 Mar 2002 21:30:47 +0000 From: John Poltorak Subject: Re: ISPELL v3.2.06 On Mon, Mar 18, 2002 at 12:51:02PM -0800, Dave and Natalie wrote: > On Mon, 18 Mar 2002 11:33:33 +0000, John Poltorak wrote: > > > > >There is an OS/2 port of ISPELL v3.2.06 available here:- > > > >http://www.proxyma.ru/stream/bin/ispell3206r.zip > > > > > >If anyone is familiar with ISPELL can you check it out? > > > >I'd like to keep the UnixOS2 packages uptodate and this port seems > >current. > > I looked at this and I don't think it would be compatible with unix/os2. It seems to be compiled (vacc) to run in its own directory with lib under it and no english dictionary. The patches might be worth using in a recompile though. Actually, it looks as though it is built with Watcom... Does anyone know if there are any 'Watcom-isms' in the patches? If anyone has any success applying the patches and building it with gcc, I'd like to know. > Dave > -- John **= Email 21 ==========================** Date: Mon, 18 Mar 2002 23:26:41 +0100 From: Holger Veit Subject: Re: Building XFree86 v3.3.6 On Mon, Mar 18, 2002 at 04:27:20PM +0000, John Poltorak wrote: [...] > > All you have to do is to read an instruction written by Hoger, > > "xc/programs/Xserver/hw/xfree86/doc/OS2.Notes". > > I have built XFree86 v3.3.1 to 3.3.6 successfully with no trouble. > > > > If you encounter a trouble, please e-mail me before write to > > Holger. > > I got as far as Step 5 which says there should be a file added-XXX, but I > didn't find anything.... > > Is there such a file in v3.3.6 ? This applies to patching original sources only. If you take the source tree from e.g. borneo.gmd.de, you are already at the state where to run buildos2.cmd and get a bucket of coffee (or, depending on how much your EMXTREE differs from mine, maybe better a bucket of beer or whisky, YMMV). Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection)