Welcome, Guest. Please login or register.

Author Topic: A-EON Interview about Amiga's future - Distrita  (Read 11136 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: A-EON Interview about Amiga's future - Distrita
« Reply #74 from previous page: June 08, 2015, 10:36:14 PM »
Quote from: matthey (& to ThoR);790818
Paula's audio buffer size is limited by the custom chips (easily fixed with enhanced custom chips). The Amiga serial ports were limited to low speeds because of limited buffer size support. Amiga IDE was limited by small buffer sizes (and old PIO modes) until the 4000T. Without proper buffer sizes, the CPU has to do more work and the Amiga with 68k CPU has a limited pool of CPU cycles to start with. Buffer sizes were probably adequate when the Amiga was created but were barely or in most cases not upgraded with ECS and AGA. The Amiga did receive expansion boards and accelerators which fixed many of these bottlenecks.

I am not sure is this related only to slow I/O. For example your real time application, is it still working right if you have GCC compiling large source code at background at lower priority?

Try to run simple non-IO real time task at priority 0 and GCC below 0.

You might find out that GCC is loading some files from the disk and this is delegated by the OS to tasks running at higher priority than your task. Suddenly your real time task is blocked by the OS serving low priority tasks.

To me it seems that if you dont raise your own priority over OS tasks you dont get served as expected. It doesnt matter how fast your system is. As long as you are running at priority lower than 10 the scheduler cant guarantee you fair share to the CPU.

Quote
Try installing Windows XP on an old 386, 486 or Pentium CPU to see how responsive it is in comparison to a 68k Amiga.

But Windows XP has lot more features than Amiga, like memory protection, built-in TCP/IP and USB stacks, and bunch of services (like you mention below).

Quote
I had the fan die in an old laptop with Pentium M (roughly the performance of a Pentium III at the same clock speed but more efficient on power) which caused the clock speed to run at 800MHz. Responsiveness was worse than most 68k Amigas even though it had some processing power in slow motion. These modern OSs with their security, features and bloat have a lot of overhead. MOS PPC Macs also are more responsive and performance efficient than with their previous Mac OS X. Any surprise?

Sure. No surprise there. But on the other hand raw performance is still same. Heavy computational tasks run roughly at same speed and it is not possible to have significant gain in the RC5-72 contest for example.
« Last Edit: June 08, 2015, 10:54:47 PM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

Offline matthey

  • Hero Member
  • *****
  • Join Date: Aug 2007
  • Posts: 1294
    • Show only replies by matthey
Re: A-EON Interview about Amiga's future - Distrita
« Reply #75 on: June 08, 2015, 11:39:03 PM »
Quote from: itix;790822
I am not sure is this related only to slow I/O. For example your real time application, is it still working right if you have GCC compiling large source code at background at lower priority?


"Real time" depends on the CPU performance and OS/multitasking efficiency so it only applies for a particular OS with a particular CPU doing specific tasks. This phrase is more commonly used when referring to embedded systems with defined bounds. Needed Cache sizes and response times can be calculated with most embedded systems but not for general purpose computers. This is why I used the phrase "near real time" when referring to general purpose computers. The AmigaOS with Toaster was real time enough for it's purposes on the Amiga where it was not possible with much faster processors on other operating systems. Throw in some more background tasks on the Amiga (like GCC compiling in the background at low priority) and the response time may have dropped too much. Add a faster 68k processor and the background tasks may be possible again with Toaster.

I asked for a lower task priority for vbcc's vc (maybe 68k only?) to be able to compile in the background while editing. Frank Wille chose a task priority of -2 which made a huge difference in editor responsiveness (major slow down to minor slow down). I am using a CSMK3 68060@75MHz with many of the bottlenecks we talked about before removed. A slower and less efficient Amiga may not feel so responsive while compiling and editing.
 

guest11527

  • Guest
Re: A-EON Interview about Amiga's future - Distrita
« Reply #76 on: June 09, 2015, 07:21:26 AM »
Quote from: itix;790822
I am not sure is this related only to slow I/O. For example your real time application, is it still working right if you have GCC compiling large source code at background at lower priority?
As far as the Amiga task system works, it should. A higher priority task will always pre-empt a lower priority task. Thus, whenever your "real time" (something like that does not exist on the Amiga) application requires the CPU, and it has a higher priority than the background job, it gets the CPU.
Quote from: itix;790822
You might find out that GCC is loading some files from the disk and this is delegated by the OS to tasks running at higher priority than your task. Suddenly your real time task is blocked by the OS serving low priority tasks.
It's not quite as bad. The FFS has a higher priority, yes, but it does not do much. It just prepares a couple of buffer pointers and then gives control back to the hardware abstraction level aka "device". Here, again the game is the same: If you have hardware that is smart enough, the device will only initiate a DMA, and hence give control back to the foreground job as long as the transfer is running. CPU time is not "burned" while waiting for the I/O.

If you are have a sorry "PIO-only" host adapter, you have a problem, though, because somehow somewhere the CPU needs to take the time from to transport the data from the disk to the RAM. That, then, of course, can really steal important time and make your day, and the device has no knowledge about which I/O it should initiate first as the origin of the request is lost. But that's not really the fault of the AmigaOs, but rather of the hardware requiring full CPU attention for I/O. It does not happen for DMA-based host adapters.

Nothing in the device, however, and nothing in the filing system - at least in the Amiga FFS - will block. The FFS is itself multithreaded (in some sense), so it can take multiple requests at once and schedule them to the device independently. I'm not so sure about these alternative "professional" or "smart" filing systems whether they can really do that. FFS can...  
Quote from: itix;790822
To me it seems that if you dont raise your own priority over OS tasks you dont get served as expected. It doesnt matter how fast your system is. As long as you are running at priority lower than 10 the scheduler cant guarantee you fair share to the CPU.
Probably task priorities do not work as you expect them to work. The priority does not define a proportionality factor for the time slice of CPU time a task gets. It is rather an absolute number of which task can pre-empt which other task. As long as there is a higher priority task requiring the CPU, all lower tasks do not get the CPU at all. That is, if there is a task running at priority one, everything at priority zero and below gets *no* time at all. (And not just "less time". I mean really: NOTHING).  Thus, if you have a foreground job at prio=1 and a background compiler job at prio=0, then the compiler does not run at all. As simple as that. Whether that's good or bad is another rmatter, but this is how exec works.
 

Offline Iggy

  • Hero Member
  • *****
  • Join Date: Aug 2009
  • Posts: 5348
    • Show only replies by Iggy
Re: A-EON Interview about Amiga's future - Distrita
« Reply #77 on: June 09, 2015, 07:46:24 AM »
Quote from: matthey;790826
"Real time" depends on the CPU performance and OS/multitasking efficiency so it only applies for a particular OS with a particular CPU doing specific tasks. This phrase is more commonly used when referring to embedded systems with defined bounds. Needed Cache sizes and response times can be calculated with most embedded systems but not for general purpose computers. This is why I used the phrase "near real time" when referring to general purpose computers. The AmigaOS with Toaster was real time enough for it's purposes on the Amiga where it was not possible with much faster processors on other operating systems. Throw in some more background tasks on the Amiga (like GCC compiling in the background at low priority) and the response time may have dropped too much. Add a faster 68k processor and the background tasks may be possible again with Toaster.

I asked for a lower task priority for vbcc's vc (maybe 68k only?) to be able to compile in the background while editing. Frank Wille chose a task priority of -2 which made a huge difference in editor responsiveness (major slow down to minor slow down). I am using a CSMK3 68060@75MHz with many of the bottlenecks we talked about before removed. A slower and less efficient Amiga may not feel so responsive while compiling and editing.


Yes, at best "near real time".
That is why you threw me with your comment about Amiga multitasking being one of the best.
I've worked with embedded OS', and Amigas don't come close in terms of true real time response, consistent performance, or reliability.
"Not making any hard and fast rules means that the moderators can use their good judgment in moderation, and we think the results speak for themselves." - Amiga.org, terms of service

"You, got to stem the evil tide, and keep it on the the inside" - Rogers Waters

"God was never on your side" - Lemmy

Amiga! "Our appeal has become more selective"
 

Offline kolla

Re: A-EON Interview about Amiga's future - Distrita
« Reply #78 on: June 09, 2015, 07:47:06 AM »
I just want to say that my main build host for Gentoo Linux/m68k was one of my A1200s with Blizzard 1260 clocked at 50MHz and with 192MB RAM. It would run gcc more or less constantly, and that never affected its responsiveness as webserver and certainly not me using vim or doing other tasks. Responsiveness only went downhill when it ran out of physical RAM and started paging much. With Linux one can adjust many parameters to adjust swap priority and still have well responding interaction.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline KimmoK

  • Sr. Member
  • ****
  • Join Date: Jun 2004
  • Posts: 319
    • Show only replies by KimmoK
Re: A-EON Interview about Amiga's future - Distrita
« Reply #79 on: June 09, 2015, 08:59:09 AM »
Buffers & 68k AOS multitasking...
In late 90's some people burned CDs with their pretty basic A2000 computers while on x86 200Mhz was said to be the absolute minimum. That's because the low overhead on Amiga.
At that time also I burned CDs with my A4000/060. I did not have burnProof capable CDRW drive (nor burner SW supporting burnproof). I had to use pretty large buffer so that A4000 had time to transfer enough data with some 4x burn speed. And .iso had to be prepared beforehand. But it was possible and worked reliably with just 50Mhz.
IIRC, with 060/50 I did not need to have very large buffers. And I think I had executive shuffling all my heavy tasks to lower priority automatically. near-realtime needing apps were automatically left as they were or they were promoted higher than 0 priority.

To me Amiga of late 90's was unusable without executive as I used multitasking very heavily all the time.

hehe... and the classic.... trying to handle a floppy disk with x86 was a nightmare always vs how it worked on Amiga ... floppy or serial I/O could destroy x86 computer responsiveness totally, while Amigas did not show any negative effect.
(actually, even today, USB still kills my i5 laptop responsiveness sometimes, nothing seem to run runs beside Win kernel...)
« Last Edit: June 09, 2015, 09:03:44 AM by KimmoK »
- KimmoK
// Windows will never catch us now.
// The multicolor AmigaFUTURE IS NOW !! :crazy:
 

Offline ElPolloDiabl

  • Hero Member
  • *****
  • Join Date: May 2009
  • Posts: 1702
    • Show only replies by ElPolloDiabl
Re: A-EON Interview about Amiga's future - Distrita
« Reply #80 on: June 09, 2015, 02:07:52 PM »
I found out what happened to BeOS it was later re-released as Zeta by magnussoft. Last release was in 2007.
Go Go Gadget Signature!
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: A-EON Interview about Amiga's future - Distrita
« Reply #81 on: June 09, 2015, 06:17:42 PM »
Quote from: Thomas Richter;790842
As far as the Amiga task system works, it should. A higher priority task will always pre-empt a lower priority task. Thus, whenever your "real time" (something like that does not exist on the Amiga) application requires the CPU, and it has a higher priority than the background job, it gets the CPU.  It's not quite as bad. The FFS has a higher priority, yes, but it does not do much. It just prepares a couple of buffer pointers and then gives control back to the hardware abstraction level aka "device".

Here, again the game is the same: If you have hardware that is smart enough, the device will only initiate a DMA, and hence give control back to the foreground job as long as the transfer is running. CPU time is not "burned" while waiting for the I/O.

This is only true when you are reading file sequentially. You can do "nasty" things like ExAll() some huge directory. Likewise using Examine()/ExNext() is "friendly". But again MatchFirst()/MatchNext() with the callback hook... even just Lock()ing a file is relatively expensive operation.

Big oops.

Quote
If you are have a sorry "PIO-only" host adapter, you have a problem, though, because somehow somewhere the CPU needs to take the time from to transport the data from the disk to the RAM. That, then, of course, can really steal important time and make your day, and the device has no knowledge about which I/O it should initiate first as the origin of the request is lost. But that's not really the fault of the AmigaOs, but rather of the hardware requiring full CPU attention for I/O. It does not happen for DMA-based host adapters.

But it does happen when you use RAM disk or DynamiCache since they dont use DMA. Just unpack large archive to RAM disk...

I dont see where "near real time OS" comes from when conditions are random. Works most of time but dont do this or that.

Even just OpenLibrary() is enough to let higher priority tasks to miss their deadline as OpenLibrary() can have very long Forbid().
« Last Edit: June 09, 2015, 06:21:23 PM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

guest11527

  • Guest
Re: A-EON Interview about Amiga's future - Distrita
« Reply #82 on: June 09, 2015, 06:28:50 PM »
Quote from: ElPolloDiabl;790854
I found out what happened to BeOS it was later re-released as Zeta by magnussoft. Last release was in 2007.

Remember its huge success? No? See, this is exactly what I think about attempts to create new operating systems.
 

guest11527

  • Guest
Re: A-EON Interview about Amiga's future - Distrita
« Reply #83 on: June 09, 2015, 07:04:49 PM »
Quote from: itix;790859
This is only true when you are reading file sequentially. You can do "nasty" things like ExAll() some huge directory. Likewise using Examine()/ExNext() is "friendly". But again MatchFirst()/MatchNext() with the callback hook... even just Lock()ing a file is relatively expensive operation.
Yes. Or mostly. The FFS management functions are not threaded, but rather go back to the device. As long as the device requests blocks from the hardware, and as long as the hardware runs on DMA, your task gets the CPU. If the directories are buffered, then the FFS copies directly from its buffers. It does not make sense to preempt this operaion as the CPU is required for this anyhow.  
Quote from: itix;790859
But it does happen when you use RAM disk or DynamiCache since they dont use DMA. Just unpack large archive to RAM disk...
Yes, certainly, but what else can a single CPU do? Either, you copy the data to the RAM, or you don't. But you need the CPU for that, so the time for that needs to come from somewhere.  
Quote from: itix;790859
I dont see where "near real time OS" comes from when conditions are random. Works most of time but dont do this or that.
It's not a real time Os, not even close. I don't know who claimed that, but I didn't. For that, it would need to guarantee maximal reaction times for certain operations, which it certainly can't. A task can Forbid() at any time and thus lock out any other operation for an infinite amount of time, a big no-no for any real-time Os.  
Quote from: itix;790859
Even just OpenLibrary() is enough to let higher priority tasks to miss their deadline as OpenLibrary() can have very long Forbid().

Well, OpenLibrary() does have a Forbid(), but not a long one. It rather uses the Forbid() to scan through the library lists. If it does not succeed there, then exec (or rather, ramlib) calls Permit() and creates a message to the ramlib task to load the library from disk. As soon as the message comes back, it tries again. The amount of blocking imposed by OpenLibrary() is thus not higher than that of any other disk-based operation. Besides, any disk based operation will break a Forbid() since it includes a Wait(), or at least two: one of the task waiting for the filing system, and one of the filing system waiting for the device.
 

Offline kolla

Re: A-EON Interview about Amiga's future - Distrita
« Reply #84 on: June 09, 2015, 07:26:34 PM »
@KimmoK

I used to have an old 486 with a tower of CD burners to provide software and other material to students. The CPU is not much of an issue here, it all boils down to I/O, and having DMA SCSI is a major plus compared the typically CPU hungry IDE.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: A-EON Interview about Amiga's future - Distrita
« Reply #85 on: June 09, 2015, 07:40:51 PM »
BeOS exists today as the open source project Haiku, and they are progressing steadily, participate yearly in Google's Summer of Code (which also resulted in rudimentary IPv6 support 4-5 years ago). There is hardly any cause for "Be-littling" when wearing an Amiga hat. Haiku has all the stuff Amiga users moan about constantly, but it is a different user experience.

https://www.haiku-os.org/
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline wawrzon

Re: A-EON Interview about Amiga's future - Distrita
« Reply #86 on: June 09, 2015, 07:46:44 PM »
Quote from: Thomas Richter;790861


Well, OpenLibrary() does have a Forbid(), but not a long one. It rather uses the Forbid() to scan through the library lists. If it does not succeed there, then exec (or rather, ramlib) calls Permit() and creates a message to the ramlib task to load the library from disk. As soon as the message comes back, it tries again. The amount of blocking imposed by OpenLibrary() is thus not higher than that of any other disk-based operation. Besides, any disk based operation will break a Forbid() since it includes a Wait(), or at least two: one of the task waiting for the filing system, and one of the filing system waiting for the device.


looks like a reason why one gets that annoying ramlib error eventually one doesnt even know where that does come from..
 

guest11527

  • Guest
Re: A-EON Interview about Amiga's future - Distrita
« Reply #87 on: June 09, 2015, 07:51:46 PM »
Quote from: kolla;790864
BeOS exists today as the open source project Haiku, and they are progressing steadily, participate yearly in Google's Summer of Code (which also resulted in rudimentary IPv6 support 4-5 years ago). There is hardly any cause for "Be-littling" when wearing an Amiga hat. Haiku has all the stuff Amiga users moan about constantly, but it is a different user experience.

https://www.haiku-os.org/

I'm not wearing any hat, and I'm not making any statement about the quality of their Os. I'm only observing that their user basis is "next to nothing". Look at the popularity of Linux, compared to other Os installations: That's probably a whopping 1%. The times where you could write your custom Os for custom hardware and make that a success story are over.

Thus, if you want to waste your time there, I've really no objections, why should I. But I've better plans with my life. (-:
 

Offline Fransexy_

  • Sr. Member
  • ****
  • Join Date: Feb 2005
  • Posts: 317
    • Show only replies by Fransexy_
Re: A-EON Interview about Amiga's future - Distrita
« Reply #88 on: June 09, 2015, 10:25:01 PM »
Quote from: Thomas Richter;790860
Remember its huge success? No? See, this is exactly what I think about attempts to create new operating systems.


Microsoft did his (dirty) part to it not were a success


http://www.internetnews.com/ent-news/print.php/3073811/
DON\'T TAKE LIFE SO SERIOUSLY AFTER ALL NOBODY GETS OUT ALIVE OF IT
 

Offline wawrzon

Re: A-EON Interview about Amiga's future - Distrita
« Reply #89 on: June 09, 2015, 11:05:56 PM »
Quote from: Fransexy_;790873
Microsoft did his (dirty) part to it not were a success


http://www.internetnews.com/ent-news/print.php/3073811/


yawn...