PC still playing Amiga catchup

[Trev]

Out of curiosity, does anybody know enough about hid game controllers to comment on if it's possible to get events from it with less than 1 ms between events? I know USB latency *round* trip is like 5 ms.

You could create a device that samples at an arbitrary frequency and buffers the data to the host system. You wouldn't get the data in "real-time," but it wouldn't matter. As long you process the data appropriately prior to the next screen update, you have the appearance of submillisecond sampling. This is where the psychology of user interaction and a cost-benefit analysis of your input scheme comes into play.

[Trev]

How come MP3 sounds like uncompressed linear 16-bit audio?  Sometimes you can't tell the difference.  You can't go by feeling; you have to look at it logically that it CAN make a difference.

MP3 sounds like crap, but not everyone can hear the distortion, and in fact, younger folks prefer MP3 to state of the art lossless codecs. Odd.

So they are playing catch-up.  PCs aren't real-time systems like Amiga is in terms of accuracy.

We really need to stop mixing terms. If Windows XP guaranteed that all operations completed within one year, it would be a real-time system, albeit a "slow" one. Neither Windows nor Amiga OS are real-time operating systems; however, both Amiga systems and modern PCs are capable of running real-time operating systems. Yes?

[Trev]

Re-read the post.  They are not real-time systems like the Amiga.  Any system can be declared to be real-time.  But PC is not as good as Amiga so don't equate them in regards to real-time operations.

Listen, one could write a simple real-time operating system that is source compatible (with a small HAL, of course) with both Amiga and IBM PC-compatible hardware. Both systems would perform identically within the domain of the real-time operating system because that's what the real-time operating system guarantees.

No one disagrees that the joystick ports on the Amiga provide lower latency access to traditional digital joysticks; however, that doesn't make the Amiga "better."

No human being can trigger a joystick at an input frequency of 1 kHz. (Something other than a human being might, but we're talking about human beings.) The problem then is one of message passing and message processing. Any software system that guarantees that 100% of the messages sent from the joystick to the host system will be received and processed within a certain period of time is making a real-time guarantee. This you know. However, it doesn't necessarily need to sample the joystick at a frequency of 1 kHz unless that's the only way to guarantee that no messages are missed. Under most circumstances, a real-time system running on IBM PC-compatible hardware can make the same guarantees as a similar system running on an Amiga. I'm not talking about 500ns response windows. I'm talking about simple message processing.

Of course, none of this explains why Photoshop CS4 64-bit has such a hard time moving the cursor when GPU acceleration is enabled. WTF? ;-) Something silly on my end, I'm sure.

EDIT: Just to be clear: "real-time" does not mean instantaneous.

[Trev]

Not everyone can play tennis, cricket, and basebell or shoot targets. The world's fastest tennis serve crossed the court in 326ms. Nice. Regardless, ~200ms is the magic number, and it's what you need to shoot for to make something appear instanenous.

[Trev]

Happy to oblige ... double the usual amount especially for this thread

If you didn't draw it on an Amiga using quick palette swapping and high frequency joystick sampling, it's off topic. Sorry. :-(

[Trev]

The Killer NIC is cool (and if it could be used in an Amiga host environment, even coolor), but the problem with the Killer NIC and other types of TCP/IP offload engines is that they are often quickly outpaced by host CPUs and stacks. The Killer NIC, though, provides a complete host environemnt in and of itself, akin to a single board computer, so its usefulness extends beyond simple offloading.

[Trev]

Are you going to surrender the ship, are you going to quit, even though he is totally wrong, are you going to let this misguided person win this debate, are you ready, willing and able to accept defeat and admit that the PC still playing Amiga catchup?

No, I'm in the relevancy camp. No human can trigger a joystick input at 1 kHz, and no mainstream Amiga-compatible display has a refresh rate of 1 kHz. It's really a question of whether or not both an Amiga and a "PC" can sample, process, and respond to an input event in a timeframe that matters to both the application and the end user. In short, they both can.

Limiting the criteria under which either an Amiga or a "PC" can be said to be "still playing ... catchup" is a sad, sad way to win a debate in general terms. NTSC Amigas are faster than PAL Amigas, but that won't stop anyone from arguing over which is "better" in terms of end user experience. Change of subject: PAL Amiga still playing NTSC Amiga catchup?

My one thousandth post should have been more interesting.

[Trev]

or "the registry isn't so bad", knowing full well that the registry is an abomination

How is the registry an abomination? I'm not looking for a debate; I'm just curious as to why you think it is.

A simplified abstraction of the registry is the tooltype, but rather than store named values in a shortcut (which is just an instance of the IShellLink object persisted to disk), they're stored in a centralized database.

The registry is more flexible than an initialization file, and if necessary, the two can be used hand-in-hand through mapping and redirection, assuming standard Windows APIs--GetPrivateProfileString(), SetPrivateProfileString(), et al--are used by the target application. In a multi-user system, you can work wonders with the registry at the data level that just aren't possible with initialization files. (You can get quite crafty with initialization files, but at some point, you end up with a database-like series of overlays, i.e. the registry.)

Granted, the hierarchical nature of the registry often leads to unnecessary complexity, but when used properly, the registry is a valuable tool.

[Trev]

It's useful until it becomes corrupt and renders the entire system unbootable. And of course, you have to deal with applications that write stuff to it and never remove it (bloating it) and spyware/viruses screwing with it. Continuously reading/writing same file means higher probability of failure of system than reading/writing different files.  I have seen several systems that wouldn't go into Windows because of registry corruptions.  I suppose you can get "lucky" if the back-up didn't get corrupted as well.  However, it would still affect start-up/shut-down times since you could corrupt the registry if you just turn off the machine and restoring it would increase start-up time.

None of those points are specific to Windows or the registry. They affect all systems. I've seen several systems with corrupt registry files as well--several out of tens of thousands. In all cases, the corruption was caused by a disk fault, and all could have been prevented if the end user had been paying attention to the diagnostic warnings generated by the disks.

I've had more issues with corrupt files on OFS/FFS file systems over the last few months than I've had with NTFS file systems over the entire history of Windows NT.

[Trev]

however my A1200 multitasks smoothly, and always prioritises my input over anything else that might be needing CPU time.

I'm just randomly jumping in, but that statement is simply not true. Exec's scheduler provides absolutely no guarantees regarding input. I'll grant you this, though: If every Amiga developer wrote solely to published APIs (not directly to hardware) and used priority levels recommended for user-level applications, then Exec's scheduler would give the appearance of prioritizing input over other system activity.

A more advanced scheduler could in fact provide such a guarantee. Exec didn't do anything that any decent workstation OS didn't already do better. What it did do--and we all know this--was provide workstation-like mutlitasking to consumers at a very affordable price. If Exec had done everything BSD, System V, VMS, NonStop, and other contemporary systems did at the time, it would have been outside the budget of all but the wealthiest consumers. (EDIT: And having been cross-developed on SunOS systems, I can't help but wonder if Carl and the rest of the gang weren't tempted to "borrow" features.)

[Trev]

I argued that the amiga can change the scheduler without a reboot...

The "Amiga" can't--a third party product can. Anyone so inclined (and qualified) could write a similar extension for Linux or Windows.

And Linux needs a different kernel altogether to boot from to change the scheduler.  And who knows what other changes you didn't bargain for might be in that kernel..

Who knows? You do. You have the source.

[Trev]

Yeah, parallelism and math units may be priority because everything is already standardized toward some API, but it would be better if hardware level compatibility was standardized and then API can still be built on top of that.

Hardware was standardized. The PC market eventually settled on VGA, and all was well. Along came 3dfx, the Glide API, and Quake, and all of a sudden, VGA didn't satisfy the demands of the market. Nvidia stepped in with the Riva TNT, and along with Id and a few other major software players of the time, Nvidia helped bring OpenGL to the mainstream consumer market. It continues today, albeit with fewer major players.

If hardware were standardized, no one solution would stand above the rest, and the market would stagnate and eventually die. Standardizing APIs allows both hardware and software designers to innovate without interfering with the other's core competencies. It's a good place to be. Really. (The APIs aren't technically standardized either. You have lots to choose from. More competition, more drive to innovate.)

[Trev]

I don't think it's disk fault as reformatting disk drive or reinstalling registry (if you had backup and had used FAT32 and booted via DOS) made system useable again.

Reformatting or restoring the file would most likely place the data on a good sector, leaving the bad sector unused and waiting for the next unwitting block of data to be written to it. It depends on the disk and the allocation scheme used.

Yeah, there's MTBF of disks, but the idea of writing to same file over and over again for all that information verses many different files makes disaster bigger on registry than on Amiga. Amiga disk failures are due to MTBFs or disks lying around in dirt/damp places.

Of course, but it could also be caused by an interruption to the OFS/FFS file system routines, which are in no way fault tolerant.

The most likley cause of the problem in both cases (regsitry on NTFS v. arbitrary data on OFS/FFS) is a disk failure or a catastrophic system failure. Edge cases related to file system deficiencies and unsynchronized access to data structures are less common, but NTFS obviously has an edge over OFS/FFS.

[Trev]

More APIs less hardware standards translates to: (1) More confusion, (2) more inexactness, (3) more restrictions as to what a standard game/application can do, (4) more inefficient code, (4) more bloated OSes with hundreds of drivers and different APIs supported.  If they had just standardized the I/O ports or memory map areas, then the competition can still be there.

By defining those standards, you limit innovation. How wide are the ports? 1 byte? 4 bytes? 8 bytes? How large is the framebuffer? 256 kilobytes? 4 megabytes? 256 megabytes? 1 gigabyte?

The only surefire way to provide both backward and forward compatibility is an API, regardless of where that API is implemented.

[Trev]

It's not done in parallel usually.

It's not? Even the Amiga did things in parallel, hence the sensitivity to actions that interfered with system timing, e.g. a CAS instruction.

Most (not all, but most) new systems sold today have at least two CPU cores, never mind the number of independent execution units on the cores themselves. Parallel execution is now the de facto standard, whether your software is aware of it or not. You can ignore parallel execution, of course, but only to the detriment of the rest of the system.

[Trev]

What, you mean something like this:

This setting changes the length of the quantum assigned to tasks. By default, the applications/programs setting assigns a quantum of 2 ticks to background threads and 6 ticks to threads owned by the foreground process. The background services setting assigns a quantum of 12 ticks to all threads. You can also modify the default and boosted tick counts.

So, Windows doesn't allow you to change the scheduler, but it does allow you to change the behavior of the scheduler.

Linux allows you to change the scheduler, but the different schedulers are sometimes just variations on the same theme, i.e. variable v. fixed quantums.

Both systems implement some form of priority boosting. Windows supports accounting (scheduling metadata) through various add-ons. Linux probably does, too, but I don't know off the top of my head.