Quoth PepperElf
View Post
Announcement
Collapse
No announcement yet.
It's a performance issue!
Collapse
This topic is closed.
X
X
-
The Rich keep getting richer because they keep doing what it was that made them rich. Ditto the Poor.
"Hy kan tell dey is schmot qvestions, dey is makink my head hurt."
Hoc spatio locantur.
-
Quoth LostMyMind View PostBecause, older computers can't get ahead of itself.... seriously.
Windows is not really built for multi-processors, regardless of what microsoft wants to hype. Newer computers have nifty dual-processing and things get done before it needs to be done. Compound that over and over again, you'll get a flaky system.
My older computers, I don't have to wait to start queuing stuff to do. However, my main one. Oh no, I must wait until it's completely ready. Otherwise, errors start coming out. It's my own fault, I like my old software too much.
Multiprocessing has been around far longer than Windows.
As for defragging,
Sure. Wear out your disk all that much quicker for some infinitesimal, if any, gain.Supporting the idiots charged with protecting your personal information.
Comment
-
Quoth otakuneko View PostI do not buy it.
Multiprocessing has been around far longer than Windows.
Now that multiprocessors are common. Up until Vista, microsoft was just starting to stabilizing multiprocessing, however there are still several programs (and programmers) that still process (or code) the old way which gets messed up when things are done out of order.
While I personally dislike Vista, at least it better at internally support multiprocessing as long the software that you're running is done correctly. But it's still not true multiprocessing; each application is assigned a thread, which is assigned to a processor, which runs until that thread "finish" and gives control back to windows. Which is why "slow down" application still work for windows.
Now mainframe OSes are a different story, when you run an app under an mainframe. That app is not in control of it's data stream. The OS will move the data to whichever processor/time slice it determine that user/app has at that moment. Once that time slice is up, the OS gives the next guy in the queue access to the processor regardless of the state of the first app process. Which is a true multiprocessing OS. Processors still can only do one command at a time.I've lost my mind ages ago. If you find it, please hide it.
Comment
-
Quoth LostMyMind View PostIf you don't believe me, watch your multiprocessor CPU usage while running a older app/game. You'll see that one CPU will be practically doing nothing. True multiprocessing OS will spread the workload across all processors under the OS control.
If you'd like, I'll write some long running single threaded demo apps for you that generate a lot of CPU usage and you can run them on a host of different operating systems. You will see the same behavior across all of them.
As to why the program won't switch to running on a different CPU? Modern CPUs have a highly predictive pipeline architecture. They break down any given single instruction into a series of steps. That pipeline architecture means that, on modern CPUs (say, post Pentium II) the CPU will be running many instructions simultaneously (I've even heard of 32 stage pipelines). Setting up such a pipeline is an expensive operation, and jobs will not be moved between CPUs without a very good reason.
Quoth LostMyMind View PostNow that multiprocessors are common. Up until Vista, microsoft was just starting to stabilizing multiprocessing, however there are still several programs (and programmers) that still process (or code) the old way which gets messed up when things are done out of order.
As such, Windows XP was, basically, waiting for it to become common place.
Quoth LostMyMind View PostBut it's still not true multiprocessing; each application is assigned a thread, which is assigned to a processor, which runs until that thread "finish" and gives control back to windows. Which is why "slow down" application still work for windows.
Cooperative multitasking requires programs to return control to the operating system before other jobs can resume.
Preemptive multitasking sees the operating system decide when to take control back from programs.
The whole page on Computer Multi-Tasking is actually very informative on these topics.
Windows NT, 95, 98, 98SE, ME, 2000, XP, XP64, 2003, and Vista are all preemptive multitasking. As are Mac OSX, Linux, and all varieties of UNIX, plus the various mainframe OSes (z/OS, S/390, AS/400, and others).
Quoth LostMyMind View PostNow mainframe OSes are a different story, when you run an app under an mainframe.
Quoth LostMyMind View PostProcessors still can only do one command at a time.
I hate to defend Windows, I really do. But, if you want to tear it down, do so using valid reasons. I'll help you there. But the reasons listed above simply aren't on that list.
Comment
-
Quoth Pedersen View PostI'm sorry, but this is incorrect. A multiprocessing OS is incapable of doing anything other than this. For proof, I point you to Linux, and any other UNIX. If you run a program that does its processing in a single thread, you will see one CPU run that job, period. Which CPU is running that job can change over the course of the job, but only one CPU can run it.
Quoth Pedersen View PostIf you'd like, I'll write some long running single threaded demo apps for you that generate a lot of CPU usage and you can run them on a host of different operating systems. You will see the same behavior across all of them.
Quoth Pedersen View PostAs to why the program won't switch to running on a different CPU? Modern CPUs have a highly predictive pipeline architecture. ...Setting up such a pipeline is an expensive operation, and jobs will not be moved between CPUs without a very good reason.
Quoth Pedersen View PostI am no fan of Windows, of any variety. However, I will defend them here: Windows XP is built from Windows 2000 which is built from Windows NT, which is a completely different code lineage from Windows ME/98/95/3.1. Windows NT was built to handle multi-CPU from the ground up (amongst other things).
Quoth Pedersen View PostThis is the difference between cooperative multi-tasking and preemptive multi-tasking......The whole page on Computer Multi-Tasking is actually very informative on these topics.
Quoth Pedersen View PostWindows NT, 95, 98, 98SE, ME, 2000, XP, XP64, 2003, and Vista are all preemptive multitasking. As are Mac OSX, Linux, and all varieties of UNIX, plus the various mainframe OSes (z/OS, S/390, AS/400, and others)......
I hate to defend Windows, I really do. But, if you want to tear it down, do so using valid reasons. I'll help you there. But the reasons listed above simply aren't on that list.
If windows was a true multi-processor OS, it would be impossible to "lock" up the OS. But for personal PCs, the overhead to have a true multi-processor OS would be pricey (performance wise) and would not come about. Maybe one day it will, when quad processors become common.
However, back to the topic....
If you have a dual processor computer with windows XP on it, it can and will have issues if apps try to do things while the OS (more accurately, the graphical interface) isn't completely loaded. This don't happen with single CPU running XP. Because the app that trying to do something can't jump the line by running on the 2nd CPU.
Which is why media player crashes on my computer if I don't wait until the explorer dlls are completely loaded. I have to wait until windows switches to idle before starting up media player or it crashes explorer.Last edited by LostMyMind; 08-31-2008, 07:19 PM.I've lost my mind ages ago. If you find it, please hide it.
Comment
-
I'm impressed, I'll admit it. It's not often to see a post like this. However, I believe we are mixing up some terms due to age differences. As such, I'll now define how I've been using them. I invite you to do the same.
Multiprocessing: A system that has more than one CPU and runs separate programs on separate CPUs.
Multitasking: A system that runs multiple programs on one CPU, dividing the time that each program has on that CPU.
Cooperative Multitasking: A method of multitasking in which the program is in control of the amount of time it runs. For example, a program running on a cooperative multitasking system has the ability to monopolize all CPU, never letting another program run.
Preemptive Multitasking: A method of multitasking in which the operating system is in control of the amount of time a program runs. For example, a program running on a preemptive multitasking system is unable to tell if the instruction running immediately prior on the CPU came from that same program.
Multithreading: A way of creating what is known as a lightweight process which allows one program to have several sub-programs running under its control. More advanced operating systems have the capability to run separate threads on separate processors when they are available.
A system which is purely a multiprocessing system would be only capable of running as many programs as it has CPUs. So, if you have two CPUs, only two programs can run. Since the operating system has to have someplace to run, it would use one of them, and a single other program would run on the other one. Due to this, extremely few systems will ever be built which are purely multiprocessing systems. Instead, they will be multiprocessing and preemptive multitasking systems.
Now, with that out of the way, let's examine your post, shall we?
Quoth LostMyMind View PostPulling out Linux as a trump card while discussing how window works internally, don't give you points. However, I'm going to assume since you made this statement you never worked on a old mainframe. Also you reinforced my point that regardless of how well the OS is "faking" multiprocessing, if the app is not coded to play along, only one CPU is doing the work. Old mainframe OS don't care if the app not coded correctly or not. The processor timeslice is on the OS terms not the app. Which is not the case with windows. Unix is better at it, but it's still not true multi-processor OS.
Your description of "faking" is rather misleading, as you are implying that older "mainframe" operating systems did not do the preemptive multitasking I described above. They did, and still do.
As such, when I say "single threaded demo app", I mean an application that, as far as both the application and the operating system are concerned, spawns no other applications or threads. It just does one task (for instance, a program that simply calculates digits of pi will be a single threaded application). A multi-threaded application will be something like a web server or database server, which needs to respond to multiple incoming requests simultaneously.
Finally, if you doubt what I am saying about the preemptive multitasking on a multiprocessing system, I suggest you contact your buddies who administer those mainframes. They will confirm for you that those operating systems are doing exactly what you have described (below) as "cheating".
Though, now that I think about it, there is one other possibility: You're referring to even older systems which ran in a batch mode only. They could well be multiprocessing systems without any sort of multitasking going on. I concede to the possibility of their existence, though doubt that more than a handful are still in use today.
Quoth LostMyMind View PostNot quite true, all processors still work the same way as they did back in the 70s. They have registers. you fill the register with data. Issue a processor command (you know assembly). Then the processor spits out a result in the register. Granted, the list of commands is bigger as well as the register. But the process is the same. You are correct in saying that each "process" is on one CPU, but there is no reason the OS can't pull the results off the register and copy it to another CPU and have that CPU do the next command. Other than the time it takes to copy the data from the register.
- Load Register
- Execute op-code
- Store Regsiter
By splitting things in this way, and designing the CPU appropriately, each of those phases can be executed independently in the same clock cycle for three different instructions. This is called pipelining. That article covers the subject in a great deal more depth. Coupled with everything else I have to say, I'd run out of space in this post (only a 15000 character limit).
Quoth LostMyMind View PostPersonally I like windows, it is my OS of choice. However, I'm not going to believe the media hype that microsoft put out. NT, 2000 as well as XP all have code from win9x/3.1 in their system. Granted alot of been replaced. But there is a difference between being able to support having more than one CPU and being an multi-CPU OS. Windows NT/2000/XP is not an multi-CPU OS. In fact, an common trick in those days was to set NT "network" dlls (which are apps) to run on the 2nd CPU (for those lucky few that had funds to buy multi-CPU boards) while the file system ran on the 1st CPU. Win9x/me/3.1 (imo) are not true OS. It's a graphical interface to DOS. Which really sets of another off-topic annoyance of mine which I'm not going to get into.
Oh, and your belief is not required for Windows NT code line to be preemptive multitasking and multiprocessing. It has been so for an extremely long time (longer than I've been working with it, which goes back to 1995). You do not have to believe it for it to be fact. Much like the moon landings.
Quoth LostMyMind View PostMulti-tasking have nothing to do with how many processors you have. Multi-tasking is purely the rules of having multiple applications playing nice to each other. I'm talking purely OS. And window OS itself, is not an multi-processor OS. It supports having access to more than one CPU. But the OS don't say what CPU does what work, the apps running on top of the OS do.
Quoth LostMyMind View PostWhile it's nice that you list quite a few modern mainframe (or mini-mainframe) OSes. Now that CPU are faster, OS cheat more. However, I'm talking older than that. Again, I was speaking purely on the multi-processing, not multi-tasking. My reasons are valid, and I don't live by some wiki list. I was there in those days. I lived it. I code for all those OSes. I've decompiled and tracked down issues with windows dlls (not by choice, I hated doing that). Wrote overrides to get around those issues. I know exactly how the internal processes work regarding windows. Since Vista came out after I retired, it's the only window OS I can't speak regarding it's internal process from experience.
Quoth LostMyMind View PostIf windows was a true multi-processor OS, it would be impossible to "lock" up the OS. But for personal PCs, the overhead to have a true multi-processor OS would be pricey (performance wise) and would not come about. Maybe one day it will, when quad processors become common.
Quoth LostMyMind View PostIf you have a dual processor computer with windows XP on it, it can and will have issues if apps try to do things while the OS (more accurately, the graphical interface) isn't completely loaded. This don't happen with single CPU running XP. Because the app that trying to do something can't jump the line by running on the 2nd CPU.
Race condition: A condition wherein two programs compete to get access to a resource. This will result in an intermittent bug. Sometimes, things will work smoothly, as the resources are accessed in the proper order for both programs to get what they need in the order they expect. Other times, they will not work, as other processes on the system slow down one of them, and the necessary resources are not acquired in the required order, resulting in crashes.
Now, what you've described is a race condition. When everything is running on one CPU, the OS scheduler manages to complete its resource acquisition correctly, and everything works. But, add in the second CPU, and suddenly the other application is able to work a little bit quicker, and the OS doesn't complete its resource acquisition correctly. Boom, crash.
This has nothing to do with whether or not Windows is a multiprocessor OS, and everything to do with a bug, either in Windows itself or a 3rd party app or driver. It should be fixed. But it does not remove the multiprocessor or the multitasking status from Windows as an operating system.
Quoth LostMyMind View PostWhich is why media player crashes on my computer if I don't wait until the explorer dlls are completely loaded. I have to wait until windows switches to idle before starting up media player or it crashes explorer.
Comment
-
Quoth Pedersen View PostI'm impressed, I'll admit it. It's not often to see a post like this. However, I believe we are mixing up some terms due to age differences. As such, I'll now define how I've been using them. I invite you to do the same.
For simplicity stake, they don't exist anymore. Since CPUs have gotten so fast. It's most likely not going to exist again. (outside special OS made by math and physic grads, which I don't think they do anymore either)
Quoth Pedersen View PostAs such, when I say "single threaded demo app", I mean an application that, as far as both the application and the operating system are concerned, spawns no other applications or threads. It just does one task (for instance, a program that simply calculates digits of pi will be a single threaded application). A multi-threaded application will be something like a web server or database server, which needs to respond to multiple incoming requests simultaneously.
You are correct in the fact that an app coded will now days be ran on a single processor regardless of how many CPUs is attached to the machine. However, lets say you ran that heavy computing pi application on a 10 CPU computer that was running windows NT that has 500 other applications running at the same time.
A true multi-processor (CPU) OS, will move your app to around to whichever CPU is free. When the timeslice comes around again, the same CPU may not be free and moves the register (or pipeline which is just a bigger register) data to a free CPU. Windows does not do this. Which is why I say it's "faking/cheating".
However web/database servers still respond to 1 incoming request at a time. Once it accepts the incoming request, it spawns a thread (which is a fancier way of starting another copy of the same program in the same memory space) and transfer it to that thread. Then the "thread" competes the request and terminate itself. At least that how I wrote my database server..... If we go back in time before "threads", you actually had to write 2 apps. The first just watch the incoming port, when a request came in. It launch a new copy of the 2nd app with the reassigned port that it told the incoming request to redirect to.
Quoth Pedersen View Postthough doubt that more than a handful are still in use today.
Quoth Pedersen View PostActually, processors have augmented that method quite a lot. As I said, they now include pipelines which allow them to execute several steps in parallel.
And the parallel thing, is just spliting the 64 bit processor into two 32bit processors for a short time to process two 32bit commands in parallel.
Quoth Pedersen View PostWell, we happen to agree on something there. Actually got into an argument with a college professor who told the class that Windows 95 was a true OS.
Quoth Pedersen View PostOh, and your belief is not required for Windows NT code line to be preemptive multitasking and multiprocessing. It has been so for an extremely long time (longer than I've been working with it, which goes back to 1995). You do not have to believe it for it to be fact. Much like the moon landings.
It's possible, I may just not be explaining it clearly enough.
Quoth Pedersen View PostNice slam there.
Quoth Pedersen View PostI've found my own problems with other people's code at all levels (application, driver, and OS modules). I've had to write workarounds for them, too. You're right, that stuff sucks.
Quoth Pedersen View PostSo, you're saying that it is impossible to lock up Solaris, Linux, AS/400/ z/OS, S/390? After all, they are true multi-processor OS'es.
Solaris and Linux while may support multi-processors. I don't include them in my list of true multi-processor OS.
AS/400, z/OS, and S/390 are mini-mainframe OS. They were designed to be a branch from the old (or should I say ancient) mainframes to the modern faster smaller systems. They have their problems. However it takes alot to crash em. But locking them up, no. It's crash (system wide) or that single app is in a continual loop (which don't effect any other app).
Quoth Pedersen View PostReality check: All of them can be locked up by a regular application if that application is coded properly. Heck, it's possible to lock up anything if you have enough information about it. None of these systems are perfect. Being a multiprocessor OS won't fix that. If anything, it will make it easier, as these systems get ever more complex.
Just in case, I'll define "locking up" as in the OS lost control to an application and the OS can't take it back. And "crash" as in blue screen (since everyone knows what a blue screen is).
Quoth Pedersen View PostActually, that is something else entirely.....Now, what you've described is a race condition. When everything is running on one CPU, the OS scheduler manages to complete its resource acquisition correctly, and everything works. But, add in the second CPU, and suddenly the other application is able to work a little bit quicker, and the OS doesn't complete its resource acquisition correctly. Boom, crash.
Quoth Pedersen View PostThis has nothing to do with whether or not Windows is a multiprocessor OS, and everything to do with a bug, either in Windows itself or a 3rd party app or driver. It should be fixed. But it does not remove the multiprocessor or the multitasking status from Windows as an operating system.
Quoth Pedersen View PostIn which case, have you reported this bug to Microsoft? I'm sure they'd love to prevent this, as (at a minimum) it results in a local denial of service attack that can possibly be exploited by a malware author.
I actually talked to one of the lead developers of NT 3.5, talking about their "redesigned" vector drawing functions. Which I can plug in numbers and it will draw it in win9x but under NT I get an error. And she said, "I'll put it on my bugs list but it's unlikely that it'll change." So I had to include pre-math functions to "conditions" the numbers before sending it off to the GUI API.
The only bugs that get fix are ones that open holes to allow outside control of the OS. Or a exploit that virus writers are using. As long as nobody uses it and the legimate apps writers just work around it. It'll never get looked at.I've lost my mind ages ago. If you find it, please hide it.
Comment
-
Quoth LostMyMind View PostYou are correct in the fact that an app coded will now days be ran on a single processor regardless of how many CPUs is attached to the machine. However, lets say you ran that heavy computing pi application on a 10 CPU computer that was running windows NT that has 500 other applications running at the same time.
A true multi-processor (CPU) OS, will move your app to around to whichever CPU is free. When the timeslice comes around again, the same CPU may not be free and moves the register (or pipeline which is just a bigger register) data to a free CPU. Windows does not do this. Which is why I say it's "faking/cheating".
First off, preemptive multitasking and the multiprocessor OS are doing something very similar here that you are ignoring (and that I neglected to account for in my earlier posts. For that, too, I apologize).
Dangit, must address something else first:
Quoth LostMyMind View PostAnd the parallel thing, is just spliting the 64 bit processor into two 32bit processors for a short time to process two 32bit commands in parallel.
Here's yet another one: Instruction Pipelining. This one deals specifically with how instruction pipelines work in modern CPUs (both RISC and CISC). Please, read and comprehend that before spouting off more misinformation about what pipelining is.
It is not "splitting a 64 bit processor into two 32 bit processors". It is not even remotely similar to that.
I'm sorry, but this is really getting on my nerves the level of misinformation you are spreading on this topic. By refusing to pay attention to what pipelining is in modern CPUs, you are allowing other prejudices as regards mainframe vs non-mainframe to cloud your perception of what else is going on.
So, to return to the previous topic: Compilers (and operating systems) are written to try to take advantage of the pipeline. However, when the operating system stops a given process from running (for instance, one of the 500 other applications that you mentioned above), that pipeline is destroyed. Current CPU state information is copied off the CPU. The application is suspended. At that point, when the operating system comes back to that application, the state will be restored on whichever CPU is best suited for it (a choice made by the operating system, not by the application). For ease of potential problem diagnosis, the operating system will try to place that program back onto the same CPU. As a result, you will see cases where one application is using up all of one CPU, while the other CPU remains mostly idle.
This is by design, and does not alter the multiprocessor state of the operating sytem.
So, multiprocessor and preemptive multitasking both can move a job between CPUs. Both are likely to put it back on the same CPU when feasible.
Quoth LostMyMind View PostHowever web/database servers still respond to 1 incoming request at a time. Once it accepts the incoming request, it spawns a thread (which is a fancier way of starting another copy of the same program in the same memory space) and transfer it to that thread. Then the "thread" competes the request and terminate itself. At least that how I wrote my database server..... If we go back in time before "threads", you actually had to write 2 apps. The first just watch the incoming port, when a request came in. It launch a new copy of the 2nd app with the reassigned port that it told the incoming request to redirect to.
Quoth LostMyMind View PostOutside exploiting hardware/OS software flaws, it's not possible to lock up an mainframe OS. Because the app does not have direct control of the CPU/hardware. You are correct in the fact that anything can be crashed. But locking up, no.
"Outside exploiting hardware/OS software flaws, it's not possible to lock up a non-mainframe OS."
You can even quote it and explain why I'm wrong.
Quoth LostMyMind View PostAgain, referring to what I already said. I never said that windows did not support multi-tasking. Nor did I say that windows does not support multi-processor (CPU). All I said is windows itself is not a multi-processor OS. The OS itself, not the 100 little apps that creates the "shell", does not utilize more than one CPU. It depends on all the apps to utilize the multiple CPUs, if it doesn't. It gets queued up on the primary CPU.
Start up a video encoding program. Doesn't matter what you're encoding. Just encode something that takes a long time. Oh, and make sure it's a bad encoder, that only runs on one processor. Now, while that's going on, start up a video playback program. Ideally, the codec should use a lot of CPU to decompress the video for playback. H.264 is good for this. Start playing a video while the decode is going on.
Finally, open the Windows task manager, and look at your CPUs. You will see that both of them are busy, even though neither of those apps are running on multiple cores.Last edited by Pedersen; 09-02-2008, 01:01 AM. Reason: Removed some remarks that could be considered ageist. My apologies for letting them get in there at all.
Comment
-
Quoth PepperElf View Postlastly... the dreaded "computer doesn't work" trouble call. much nicer when they actually say what's happening, like "computer doesn't turn on" or ... at least SOMETHING more than "doesn't work". blehassholeperson who has a problem or a question with a transaction, a report, etc.
While I like it when I can just sit at my desk, listen to some tunes, and do my job, I don't mind answering questions or helping solve a problem. However, it gets frustrating when they won't give me any useful info. One day, I got a report that one of the users was using a certain transaction, which ended up going down.
I couldn't recreate the problem or figure anything out from the log, so I requested information from the user, asking them what they were doing when the transaction when down. I got a reply back with something useless like, "I was using such-and-such transaction, and it went down."
Well, no shit, Sherlock! I can see that much! How about some information I can actually use? No, I didn't say that, but I wanted to. I did, however, vent my frustration to my supervisor, who contacted the user herself and asked the user for some information we could actually use (i.e. what keys were pressed, what kind of data was being added/changed/viewed, etc.) Never got a reply back.Sometimes life is altered.
Break from the ropes your hands are tied.
Uneasy with confrontation.
Won't turn out right. Can't turn out right
Comment
-
Quoth Pedersen View PostHere's yet another one: Instruction Pipelining. This one deals specifically with how instruction pipelines work in modern CPUs (both RISC and CISC). Please, read and comprehend that before spouting off more misinformation about what pipelining is.
Instruction fetch
Instruction decode and register fetch
Execute
Memory access
Register write back
You can try to cloud it with more details, but down at the very bottom. That's what its doing.
Quoth Pedersen View PostIt is not "splitting a 64 bit processor into two 32 bit processors". It is not even remotely similar to that.
Which still has nothing to do with pipelining.
Quoth Pedersen View PostActually, this is how Apache works by default. You might have heard of it, as it is either most popular or second most popular web server around right now (forget if it, or MS IIS, is number 1 at the moment).
Quoth Pedersen View Post"Outside exploiting hardware/OS software flaws, it's not possible to lock up a non-mainframe OS."
Try doing that with AS/400, z/OS.
To quote you,
Quoth Pedersen View PostFirst off, preemptive multitasking and the multiprocessor OS are doing something very similar
Quoth Pedersen View PostWell, now we start to see a better picture of what you're talking about. Allow me to provide proof for you that you're wrong.....Finally, open the Windows task manager, and look at your CPUs. You will see that both of them are busy, even though neither of those apps are running on multiple cores.
I'm going to guess that you don't have apps that have problems running on multi-CPU computers? I have several apps that I have to tell windows to "ignore" the extra CPUs while those are running. If windows was a true multi-CPU OS, this would never happen because the apps should not care how many CPU there are.
Until windows restrict access to hardware and force apps to process through the OS. This problem will always remain. Way too many apps are allowed to bypass the OS and access the hardware manually (including the CPU).
But like you said, we're getting into "realm of CPU arcana" (or OS arcana) and we can just agree to disagree.I've lost my mind ages ago. If you find it, please hide it.
Comment
-
Quoth MadMike View PostI've gotten quite a few of those at my job. I don't deal with customers, I just do programming. However, every so often I have to deal with a user or marketingassholeperson who has a problem or a question with a transaction, a report, etc.Aerodynamics are for people who can't build engines. --Enzo Ferrari
Comment
Comment