Reason I ask, is now, when we switched from seti classic, we went to boinc. which is a windows app.
When I ran seti classic from windows xp ms dos window, I was cutting 3.5-4 hours per work unit, now with boinc 4.25, I am up to 5-5.5 hours per seti wu.
I downloaded newdos 7.1 lastnight, and ran setiathome classic on an old work unit I already finished, and it zipped to finish in 2.5 hours. That was a dramatic difference over what is running now. Same results were found with the seticlassic in xp window and seticlassic with newdos7.1 boot. yet the dos7.1 completed in around 60% of the time.
Just looking for ways to increase speed of wu completion. Never know which wu will be the one to find something real out there. That is my motivation for increasing speed.

FYI, for those interested in trying, do a google for dos 7.1, and oneof the first links is to a place called newdos.yginfo.... something
Make sure you pick the one that has dos7.1 in its name, as most of them are in chinese.
Thanks in advance for any/all comments,
John Henry
Sevierville, TN

---

Thanks, and Keep on crunchin'
John Henry KI4JPL
Sevierville TN

I started with nothing,
and I still have some of it left.
<img src="http://www.boincstats.com/stats/banner.php?cpid=989478996ebd8eadba8f0809051cdde2">

Can DOS access 128MB RAM?

---

The never was and never will be a DOS version of SETI Classic or BOINC.

I believe what you are referring to is the Command Line version of classic, which is still a Windows executable, but does not have a GUI (Graphical User Interface).

BOINC/SETI running wothout the graphics turned on, is effectively the same as Classic command line.

You should not be seeing an increase from 3.5-4 hrs to 5-5.5 hrs, the difference should be in minutes only. Perhaps you have just been issued with a particularly complex WU to process. You need to run several to get an average.

---

> Reason I ask, is now, when we switched from seti classic, we went to boinc.
> which is a windows app.
> When I ran seti classic from windows xp ms dos window, I was cutting 3.5-4
> hours per work unit, now with boinc 4.25, I am up to 5-5.5 hours per seti wu.

With BOINC, things are a bit different. Whole stuff is roughly split into 3 parts:
- management part, which takes care of communication with project servers and running other parts of suite. This part is often referred as BOINC CC or BOINC manager.
- graphics/screen saver part, which runs only if user asks for it. If that part is not enabled, then it won't consume any CPU cycles
- crunching part, which does the scientific work. This part is automatically updated per project servers request.

The latest part can be somehow compared to DOS version of the classic seti binary.

---

Metod ...

> Can DOS access 128MB RAM?

It can if you use some kind of DOS extender (together with highmem.sys or whatever to create a pool of XMS memory).

---

Metod ...

In that case, DOS should be able to trudge along using the CLI instead of the GUI, so long as networking is enabled.

MikeSW17 pretty much summed it up - You'd be on your own on that limb...

2&cent;: I won't discourage experimentation, but I think a rudimentary Linux distro would be more appropriate.

---

I have run MANY work units with seticlassic, and MANY work units with boinc, and yes, the difference is as shown in my previous mail. I'm up to over 230 now in BOINC, and the averages speak for themselves. Slower than before.
And it is only semantics, when I ran seticlassic through setispy/setidriver, that is the "dos" version I was referring to, the command line version.
And yes, DOS 7.1 can access well above 128MB RAM.

I'm only trying to find out if someone is going to make a commandline version, that I can run under dos 7.1, which from a test I ran last night, cranked out a seticlassic in 2.5 hours. The result from the test was the same data as was uploaded to seti about a month ago.

Without an upload/download manager, then this will not go anywhere.

I am trying to find something that gets rid of the crapload of overhead that windows has in its multiple layers, and get right to the lowest level of computation, as DOS has always proven far superior to windows in terms of computation speed and lack of overhead. Ask any programmer who has programmed in DOS, and then programmed in windows, and he will tell you the overhead and layers, and not'real'time problems of doing real'time'things in windows.

Thanks,
John Henry
Sevierville, TN

---

Thanks, and Keep on crunchin'
John Henry KI4JPL
Sevierville TN

I started with nothing,
and I still have some of it left.
<img src="http://www.boincstats.com/stats/banner.php?cpid=989478996ebd8eadba8f0809051cdde2">

> Can DOS access 128MB RAM?
>
Yes and No.

Certain (specially written) DOS programs can make use of memory above the 1Mb limit. But DOS is a 16bit operating system and so can only see 64Kb of memory at a time.

Programs that needed more than 64Mb (but less than 640Mb) had to manage the memory themselves - which 64kb chunk they were working with at any time - quite complex.

Memory above 1Mb used to be used sometimes for data storage - especially RAM discs, and never for executing code.

---

I ran seticlassic on dos 7.10 last night, and got the same answers as when it was under an xp window. so evidently it will work. DOS will run the seticlassic program. I do have a win95 boot that uses dos 7.10, so it works just fine. Test proved same results.

But BOINC will not run in this environment. So the upload/download manager functions are missing.

If someone built a boinc for win95, then this should work.

Is it out there? that is all I'm asking.

There should be no more discussion on whether it is possible to run a seti unit on a dos win95 machine, as I proved it last night, exactly the same output.

Again, the question, is it out there?

If not, oh well, I will continue to use what I have, just looking to see if it is done, if not, will someone take up this challenge? as I don't know how.

Thanks,
John Henry
Sevierville, TN

---

Thanks, and Keep on crunchin'
John Henry KI4JPL
Sevierville TN

I started with nothing,
and I still have some of it left.
<img src="http://www.boincstats.com/stats/banner.php?cpid=989478996ebd8eadba8f0809051cdde2">

> > Can DOS access 128MB RAM?
> >
> Yes and No.

Natively no.

Non-natively: yes

As I wrote, if you use some proper DOS extender, you can use more. Of course, this only works for 80386 and above.

http://www.delorie.com/djgpp/
http://www.tenberry.com/dos4g/
http://www.thefreecountry.com/programming/dosextenders.shtml

and some more.

---

Metod ...

Methinks a 2.4 kernel will suffice with more memory & dev support...

---

> I have run MANY work units with seticlassic, and MANY work units with boinc,
> and yes, the difference is as shown in my previous mail. I'm up to over 230
> now in BOINC, and the averages speak for themselves. Slower than before.
> And it is only semantics, when I ran seticlassic through setispy/setidriver,
> that is the "dos" version I was referring to, the command line version.
> And yes, DOS 7.1 can access well above 128MB RAM.
>

Well, it's not just semantics - do you drive on the left or the right? Do you decide which is which each day? Life would be chaotic if we all chose our own definition of words.

There is a world of difference between 16bit DOS and 32 (and 64) bit Windows.
A program written for windows will _never_ run under DOS, until you install a special support environment on top - called Windows (95 or 98).

Windows 1,2,3,3.1, 95 and 98 all _needed_ DOS to get started.
Windows NT, 2000 (NT5) and XP (NT5.1) do not have DOS. The have command line inteface that emulates many of the commands DOS has, but does not provide any operating system functionality.


> I'm only trying to find out if someone is going to make a commandline version,
> that I can run under dos 7.1, which from a test I ran last night, cranked out
> a seticlassic in 2.5 hours. The result from the test was the same data as was
> uploaded to seti about a month ago.
>

Yes, There is already a command-line version. In fact there is _only_ a command line version.

> Without an upload/download manager, then this will not go anywhere.
>

BOINC is that upload/download manager.

> I am trying to find something that gets rid of the crapload of overhead that
> windows has in its multiple layers, and get right to the lowest level of
> computation, as DOS has always proven far superior to windows in terms of
> computation speed and lack of overhead. Ask any programmer who has programmed
> in DOS, and then programmed in windows, and he will tell you the overhead and
> layers, and not'real'time problems of doing real'time'things in windows.
>

Windows doesn't interfere with computation, not in the way you seem to suggest. Windows may have other things to do sometimes, but when it hasn't, it hands the CPU over to any process that wants it.

> Thanks,
> John Henry
> Sevierville, TN
>

---

Chill dude, don't have a cow.
I'm just trying to find something that will run work units faster.
If you can't answer without getting frantic, then maybe you need to drink less coffee, as someone told me once.
If I use the wrong word, then please forgive me, don't get upset.
Afterall, this is all for unused cpu cycles, that may find something out there.
I was just trying to optimize this.
I understand completely the differences between dos and windows, and have programmed for both.
Do you wonder why DOD will not use windows in mission ciritcal computers, and allow dos? because windows is slower, less real time, cannot guarantee timing constraints, etc., there are a million reasons, and any programmer who has programmed both will know the differences.
I was trying to get to using something that the world knows is faster.
16 bit versus 32 bit is taken care of with an extender that has also been proven to show faster in dos than a normal win32 app. So that is not an issue.
Besides, there are already other apps that can take windows programs and run them on dos, with only minimal differences in speed, as compared to running the same app in windows itself. ever heard of linspire? running windows apps in emulation is faster than running windows apps on windows. I know the command line versions is available, and have already said so, but the upload/download manager is not, and was wondering if some enterprising individual has one working somewhere.
Geesh, maybe I won't ask questions anymore.
Each time I do peeps seem to jump up and down.
All over a mis-wording, or a difference...
Grow up, and start using your spare cycles to calm down.


> > I have run MANY work units with seticlassic, and MANY work units with
> boinc,
> > and yes, the difference is as shown in my previous mail. I'm up to over
> 230
> > now in BOINC, and the averages speak for themselves. Slower than before.
> > And it is only semantics, when I ran seticlassic through
> setispy/setidriver,
> > that is the "dos" version I was referring to, the command line version.
> > And yes, DOS 7.1 can access well above 128MB RAM.
> >
>
> Well, it's not just semantics - do you drive on the left or the right? Do you
> decide which is which each day? Life would be chaotic if we all chose our own
> definition of words.
>
> There is a world of difference between 16bit DOS and 32 (and 64) bit Windows.
> A program written for windows will _never_ run under DOS, until you install a
> special support environment on top - called Windows (95 or 98).
>
> Windows 1,2,3,3.1, 95 and 98 all _needed_ DOS to get started.
> Windows NT, 2000 (NT5) and XP (NT5.1) do not have DOS. The have command line
> inteface that emulates many of the commands DOS has, but does not provide any
> operating system functionality.
>
>
> > I'm only trying to find out if someone is going to make a commandline
> version,
> > that I can run under dos 7.1, which from a test I ran last night, cranked
> out
> > a seticlassic in 2.5 hours. The result from the test was the same data as
> was
> > uploaded to seti about a month ago.
> >
>
> Yes, There is already a command-line version. In fact there is _only_ a
> command line version.
>
> > Without an upload/download manager, then this will not go anywhere.
> >
>
> BOINC is that upload/download manager.
>
> > I am trying to find something that gets rid of the crapload of overhead
> that
> > windows has in its multiple layers, and get right to the lowest level of
> > computation, as DOS has always proven far superior to windows in terms
> of
> > computation speed and lack of overhead. Ask any programmer who has
> programmed
> > in DOS, and then programmed in windows, and he will tell you the overhead
> and
> > layers, and not'real'time problems of doing real'time'things in windows.
> >
>
> Windows doesn't interfere with computation, not in the way you seem to
> suggest. Windows may have other things to do sometimes, but when it hasn't, it
> hands the CPU over to any process that wants it.
>
> > Thanks,
> > John Henry
> > Sevierville, TN
> >
>

---

Thanks, and Keep on crunchin'
John Henry KI4JPL
Sevierville TN

I started with nothing,
and I still have some of it left.
<img src="http://www.boincstats.com/stats/banner.php?cpid=989478996ebd8eadba8f0809051cdde2">

and YES, windows does interfere with computing. Not on a single computation, but when running a large number crunchign endeavor, which is what seti really is, it interrupts the process a million times by the time the seti work unit is completed. and running the same in a dos emulation of 7.1 it does not.
Hence the speed I got when running the command line version in my test last night, versus the xp windows bound up multiply interrupted multi-tasked processing. without all of that overhead crap, it screams to completion.
If you don't believe me, do a google on whetstones for dos and windows, and your eyes will be opened to what time critical engineers have always known since windows was introduced.
We cannot use windows based machines to control shutdowns of time critical equipment, not in DOE, not in DOD, why? because of the multixxx environment.

---

Thanks, and Keep on crunchin'
John Henry KI4JPL
Sevierville TN

I started with nothing,
and I still have some of it left.
<img src="http://www.boincstats.com/stats/banner.php?cpid=989478996ebd8eadba8f0809051cdde2">

BOINC is multiprocess by definition ~ a manager communicating with a science application.
You will get the best results by compiling both the manager and science app for your specific system and running a stripped down optimized linux kernel with nothing else running.
Speedup compared to standard versions is about 15-30% in WU troughput.

semantics, schematics (to the tune of Laverne & Shirley)... ease up guys

i haven't programmed in DOS since 1987 if memory is correct

sounds like a pretty good idea, but a FAQ will definitely be needed for those who are sure to pop up with the "I can't..."

and of course there are alot of people out there curious/concerned about the stats and how that would be incorporated into it

there is more i'd like to say about this, but i am tired and am retiring :-)

DOS made you do WORK for your results, Windows makes it easy, just point and click...

---

No matter where you go, there you are...

Thanks Janus,
This 15-30% thruput seems to backup the speed increases I found.
Tried it with the linux kernel, and saw the same.
Less overhead, less interrupting of a process, etc., What a wonderful world it is/was.

FYI, there are still lots of dos programs being written, go look into some of the embedded worlds, either dos, or self written os's, vrtx, cmx, etc., but not windows. too slow, too interruptable when it is critical that it don't stop waht it is doing, blue screen of death would be a bad thing to see in an F16 flying mach1 100 feet above the ground with a missile coming up your butt. no time to reboot. I don't knwo of a windows based computer yet that has never crashed, and of course, making this statement with these lunatics in this forum, I can guarantee that I will get at least 50 posts in here now from people who claim their computer has never locked up, never had to hit the power button, so, i will go drink some milk, turn off this posting site for a while, and come back later and laugh at the liars.

---

Thanks, and Keep on crunchin'
John Henry KI4JPL
Sevierville TN

I started with nothing,
and I still have some of it left.
<img src="http://www.boincstats.com/stats/banner.php?cpid=989478996ebd8eadba8f0809051cdde2">

Sorry if I'm comming over cranky - it's been a long week.

I don't dispute that DOS is a reliable but light-weight OS, with a minimal overhead, but then it doesn't support much either in terms of hardware or software.
I too have programed in both, and true, I would never use Windows for real-time control. I still have applications I wrote for DOS running in the field

I the point I was trying to make, but lost it, is that Windows isn't too bad at running SETI. In fact if there are posts here that rate windows systems faster than *nix systems on the same hardware - which surprises me.

I'm sorry, I still don't understand your use of DOS 7.1, and why/how you are using it? AFAIK, there is such thing as a 16 bit version of any SETI client, and 32 bit software just won't run on a 16 bit OS.
A 32 bit operating system must have been 'in control' for SETI Classic to run, regardless of the presence of DOS 7.1 surely?

---

The why is easy, just to do it. Just to see if it can be done.
The how is also easy, download newdos7.1, install, load memory extender, himem.sys, etc., then if you want, run a winxx, and seti classic, and it is done. win95 will do nicely, as it still relies on dos to do almost everything, winxp now doesn't use dos, as it is nt based, and has loads of overhead. programming a simple serial port is very simple in xp, but to do so requires umpteen meg of code now, where dos was a few bytes, and winxp was under a k of code. but that is progress. something is wrong there.
With this configuration, I can still address ALL of the HW on my machine. including USB 2.0, SD memory, Ethernet, ultra fast EIDE hard drive, CD-ROM, and even now play DVDs on it. So the hardware limitations can be overcome, if one can find the drivers.

The why is... just to see if it can be done, and find other ways that have not been explored. I'm an engineer at heart, and always trying to find more/better/faster/fasteerrr/...

anyway, good luck, and we will see,
John Henry
Sevierville, TN

---

Thanks, and Keep on crunchin'
John Henry KI4JPL
Sevierville TN

I started with nothing,
and I still have some of it left.
<img src="http://www.boincstats.com/stats/banner.php?cpid=989478996ebd8eadba8f0809051cdde2">

AFAIK, there is such thing as a 16 bit version of any SETI client, and 32 bit software just won't run on a 16 bit OS.
Well... you could, but you'd regret the decision. That would require every 1st and 3rd clock cycle to be a memory access, every 2nd to be a shift-left, and then only on the 4th cycle would you be able to do something.

Just ask anyone who's got a Performa 5215...

.o0(...said it was a color Classic that darn sonnova...)

---