My horror stories are endless. They somehow messed up my move, and after 1 year and many many lengthy and repeated phone calls, still were not billing me at the correct address. I finally canceled all my Bell services. It was the only way I could get them to stop billing the wrong address.
Once, someone hacked Bell's backbone routers. All the tech support people would do is go: "We do not support trace route. We do not support trace route. Trace route is not installed on our computers." I finally got them to type in "tracert" at the command line. At that point, they admitted they mysteriously had to leave the phone... I seem to remember being hung up on, and never getting a call back.
The Bell outgoing email server routinely fucks up. I am pretty sure that they are tweaking the anti-spam settings, and either delete or delay the customer's email messages. Magically, my home internet connection, and all my business customers internet connections, simultaneously loose outbound email for 2 to 3 days. Then it all comes back again. Bell technical support insists the problem is that we use ThunderBird and Microsoft Outlook. Only Microsoft Outlook Express is supported on Bell's network.
Bell Technical Support is so inept: "Bell does not allow them to install any software including Microsoft Outlook Express on there computers." The next time you are trying to debug an email problem with Bell, always remember that you are talking to a person not allowed to use any email software whatsoever. Bell Tech support is only allowed Webmail.
Some of the business types are undoubtedly thinking: Why don't you stop using crappy ADSL lines, and spend $1800/month on a partial T1? Firstly, $1800/month is a significant amount of money to be spending on Internet services, especially in comparison to an $80/month business ADSL line. Secondly, I have spent that much money on fancy Bell Lines. Bell can mess them up too!
Simply put, having ISP's other than Rogers and Bell is vital for Canada's competitiveness. It's called "Bell Hell" for a reason.
It will run better with Windows Vista! and Office too! SQL Server will definitely scale to handle the workload. Some custom.NET programming may be required, but Visual Basic will make it easy. So easy that anyone can do it. No problems.
Why can I protect my WoW account better than my bank account?
Check out the terms of service on your bank account. You might be shocked to learn the bank isn't responsible for your financial losses. Often, they specifically exempt themselves from all responsibility relating to fraud, mistakes, and/or computer errors. If they cash a bad cheque, you are on the hook.
There is a reason why people that survived the Great Depression hide money under their mattresses.
the ability to always know true north... electronic compass
I've been to Northern Canada. A compass points to MAGNETIC North. True North is at the North pole, the point on which the earth spins. At true north, the sun never sets, and sometimes never rises for days on end. In summer, it has the longest days in the world. In winter, the longest nights. Magnetic north is not the same place at all...
Magnetic North has some interesting properties too. Amongst others, the Magnetic south and north poles move around, periodically flip, and do not pass through the center of the earth.
Question, are the USB serial adapters properly supported in linux (or Windows) yet? The last time I tried one the drivers were crap and it wouldn't work above 1200 baud.
In general, USB Serial under Windows is horrible. Windows XP has many USB serial ports with buggy drivers. Most devices that I tested had either data corruption issues, or simply wouldn't do high baud rates, or both. If you use the FTDI chipset based devices, then at least no data corruption occurs at high baud rates. All of the drivers that I used would fail if the USB device was disconnected while RS-232 communication was occurring, and then reconnected again. To recover, Windows XP either had to be rebooted, or the USB port reassigned to a different COM port number. A reboot for a USB driver???
Also, many older specialty programs won't work with USB serial ports. Essentially, Microsoft slightly changed the behavior of the polled mode ReadFile/WriteFile calls, so USB serial ports behave differently than built-in serial ports. This breaks old software.
USB serial ports under Windows for antiquated embedded / real-time applications can be a real nightmare. The only success I had at high baud rates was with the FTDI chipset and drivers. Even they, broke old software, and required a reboot if the USB device was unplugged during communications.
And you are worried about Linux driver support? I'm pretty sure that this is one of those cases where Linux works better than Windows.
Go for the obvious. Someone is trying to get revenge on corporation "x" by purchasing a bunch of computers and having them drop shipped. By the time accounting catches up with the paperwork, the computers will be in the hands of the FBI for a month. If the scam is done right, it is done by an ex-employee or someone with just enough access to know who the preferred suppliers are. You make a couple of phone calls, send the right paperwork, and next thing your computer vendor is drop shipping a bunch of computers somewhere.
Having worked for distributors, I'm surprised this doesn't happen more often. Having stuff go missing for weeks on end inside factories, fairly routine... This wouldn't be hard to do. Just ship a bunch of computers somewhere else.
It is even difficult to get charged for doing something like this. FAXing the paperwork leaves no fingerprints. To the accounting department, the transaction looks like typical incompetence. The corporation won't request charges laid, because then they would have to admit they were incompetent too, and this stuff happens all the time. The police have a tough time charging you, because you didn't steal anything. If done right, you didn't even touch anything so there is no physical evidence. No evidence means no crime, and your revenge makes the national newspapers. Perfect revenge scheme.
Actually, I thought about your point when the show aired. In fact, it is impossible for that planet to exist. You can't form a long-term stable orbit around a black hole. From a two-body, Newtonian point-mass analysis, yes the planet can exist. However, a planet that close to a black hole will be affected by Einstein's General Relativity, which predicts a collapsing orbit. Additionally, the planet would be experiencing severe gravitational stresses and magnetic stresses, causing it to break up or its orbit to decay. The other matter collapsing into the black hole would disrupt the "stable" orbit, also causing the planet's orbit to decay or it to break up. In short, I don't think that it is possible to have a long-term stable orbit around an black hole when it is consuming matter.
If you want a bigger plot "hole", think about where the magic gravity beam came from. Why would it come from a black hole? If it came from the planet, then why was it pointed in space? If the evil creature could create a gravity beam big enough to save a planet, then why couldn't he make a slightly bigger one and take over the universe? Maybe, we need to accept that any Sci-Fi plot will have its weak points, and suspend our disbelief.
The Satan Pit / Impossible Pit were really great Doctor Who episodes. Maybe we should appreciate them for that, instead of taking apart the physics?
I just finished looking at a paper on the subject from 1972. In 1972, wrist watches were already using special bipolar transistor circuits for low power consumption. Standard TTL was unsuitable for the application. There was already a widespread drive to switch to CMOS, starting with RCA in 1967.
The first early LSI watch chip was an Intel 5810 CMOS chip, and it is likely that is the chip in your 1979 LED wrist watch. Specifically, the Intel prototype boards used LEDs as the display for this chip.
Given the chip comes from Intel, the inventors of the 4004, it is likely that there are at least some subtle design queues taken from the other Intel products. Simply put, the architecture of a wrist watch design, specifically the multiplexed displays, really lends itself to a certain type of solution that resembles a computer design. A central data bus connecting the registers/counters saves transistors in the overall design.
Most of those old digital watch chips used a surprisingly microprocessorish architecture, and MOS (maybe even CMOS). I can almost guarantee that chip was not done with standard TTL, or even LSTTL. Your watch probably borrows from the 4004 type pre-computer architectures floating around at the time.
There are two big reasons why a standard TTL architecture is not the way to go. Firstly, TTL consumes a great deal of power, which isn't optimal for a watch.
The second reason to use a CPU-style architecture is that the LCD and/or LED (for really old digital watches) displays are multiplexed. You could build a full multiplexer to drive the displays, or your could use a data-bus like architecture. Once you have a databus, then it becomes a question of how you want to increment/decrement the counters, and if a central 4-bit adder is better than a series of counter chains floating around the chip. Either way, the counters are going to be registers, and the data will be multiplexed on the data bus to drive the LCDs. For programming, several AND-OR logic circuits are required to do the BCD counting arithmetic, the BCD to seven segment decode functions, and the function sequencing. We could discuss if the design merits the full "programmed CPU" designation, but the design will have enough stuff to look surprisingly like an early computer/counting machine/calculator design.
It sounds like Chicago's system is significantly worse than Toronto's. In Toronto, those meter boxes are everywhere. In Chicago, I think they put in many fewer meter boxes. Also, the boxes that Toronto does use, can be scammed. The boxes are also a pain when the Credit Card slot stops working / freezes in the winter, then you need more change than any normal human carries around.
Also, Toronto's rates for parking are much lower. I haven't heard of having to pay $84 for parking for anywhere in Toronto.
I'm not sure IBM Mainframe's count as POS systems. However, you are correct in that large numbers of these applications are terminal applications running on a mainframe. At first, dedicated terminals were used. Then, they switched to DOS based PCs. My bank has used both OS/2 and Windows based PCs more recently. Still the same green screen applications, however now some of them have better user interfaces.
I think it really depends on your approach. If you look at it like an embedded systems person, you are looking at the OS and technologies put into all the little small devices. I work more with machine controllers than POS systems, and they are all networks of small (or bigger) microprocessors and microcontrollers. Each device takes on a different section of the job to make parts emerge from the factory.
If you approach the systems from a datbase/big systems/accounting point of view, then you see the IBM mainframe, or the UNIX/AIX central system, or more recently some type of SQL Database. It all really depends on your area of interest.
For instance, people talk about PCs in cars. The embedded people know that the average car today is shipping with at least 4 different microcontrollers (Radio, Engine, Transmission, Body Control (Door Locks), and/or Air Bags.) For the embedded people. the computer revolution happened a long time ago. Every person has a different perspective.
The embedded market is known for its fondness of cheap hardware, and sticking to the status quo. For many years, DOS was a dominant O/S for Point of Sale applications. In recent years, Windows is getting more popular. Linux is a big portion of this market, because it is free, and has real-time extensions. You can control entire machine tools in real-time with Linux, implementing the servo-loops on a PC in software. You can even prototype embedded applications, like motor controllers, in real-time Linux on a PC, and then port to an appropriately sized embedded platform when you know your processor requirements. With embedded PC chips, like these, it may not even be cost effective to switch off the PC platform for some applications.
The 68000 / ColdFire line is getting rather old at this point. The problem is that only two platforms long-term can keep up the pace with the cost of modern processor development. The IBM Power series (including the cell for the PS3), and the Intel/AMD x86 platform. Everyone else, cannot keep up with the cost of modern processor development and the cost of fabrication facilities. Even AMD struggles to finance fabrication, with the resulting Global Foundaries spin-off. Intel struggles with the same problem too. Intel is unable to make the Itanium (Itanic) line competitive with the x86 line. The top 10 supercomputers are all either Power series processors, x86 AMD or x86 Intel. On the total Top 500 list, only a very few systems (6) use Intel Itanium. It simply costs too much money to develop a processor architecture, and only the largest architectures can remain competitive on a cost/performance basis.
There are many simple embedded applications that do use inexpensive processors. There is an entire industry developing 8-bit, 16-bit, and even some 32-bit embedded processors (including the ColdFire.) However, generally the PC is not competing in the same space. Interfacing between the 8-bit processors and the PC is becoming a challenge.
Does anyone know good ways to connect the embedded processor to a standard PC motherboard? RS-232 is becoming rare. Ethernet overwhelms the small processors with data. Any good embedded communication solutions for networked motor drive and control applications?
When you count pennies, dimes are an order-of-magnitude. Reducing the memory usage from 91K to 41K could be a micro-controller versus a micro-processor and external memory. It could be the difference between a chip that costs $11 and one that costs $8. When you are trying to find ways of eliminating 1 cent capacitors, eliminating chips represents big dollars. The embedded people think about things differently.
Linksys rewrote changed the entire software stack for the WRT54GL. They even switched operating systems, simply to halve the number of memory chips in the design.
For some embedded applications, a program size of 90kb to 41kb would result in a very large Christmas Bonus. It would be considered an order-of-magnitude reduction, and you would be a hero.
Fortran is a much older language than C++, and it supports variable sized arrays with known sizes in calling functions. It is also one of the few languages that are faster than C on supercomputer number crunching applications.
C++ should be several different languages, that can be compiled and linked together. The source files should have DEFCON levels to show how dangerous / fast they are.
DEFCON 5 - Peace. The most passive Java/Python/Scriptish code imaginable; run-time types; and built-in automatic memory management.
DEFCON 4 - Forces compile-time type checking.
DEFCON 3 - Adds Multi-processing / Cluster computing.
DEFCON 2 - Fast code; direct access to all member variables; none of the get/put call slowness; memory management is banned (no new or delete); and no aliased variables. Numerical code as fast as Fortran. Code automatically configured to work well with MPI / Cluster configurations.
DEFCON 1 - Pointers. Manual memory management.
With DEFCON levels on the source files, bugs can be contained to areas of code, and the class/optimization level of the code can become clearly visible.
a) Warp Drive is possible. In which case, there is probably some sort of faster than light communications protocol too. In which case, we just are not in the fast lane. Chances are, if someone was using Warp Drive and Faster than Light communications, we would never notice, because we know nothing about the technology. Space is also big. They may not have bothered to find us, or they might have no reason to talk to us.
b) Warp Drive is impossible. In this case, the energy budget of even traveling with small probes at 0.1c would be so huge, that it is unlikely anyone would find us. Even if a 100 million year old probe was sitting in this solar system, do you think we would find it?
Either way, space is big, we are small. Unless we have a breakthrough, we are not going anywhere.
For example: A few years ago, I wrote a paper for an conference. To get it included in the proceedings, I had to sign over the copyright to the paper to the professional organization running the conference. Giving them a non-exclusive license to reproduce the paper was not good enough; they wanted the copyright outright. Not only was I not compensated for this, it was in addition to having to pay a non-trivial registration fee to attend the conference in the first place. When I complained to my management about this, they just shrugged their shoulders and said, "That's the way it's done." So I find myself in the curious position of not being legally allowed to distribute a paper that I wrote, and neither I nor my employer were compensated for the transfer of copyright.
That is the way it works. If you include colour graphics, then many journals require payment before publishing your paper. In that case, you need to pay for the conference, and pay for the paper. In return the journal keeps your copyright, and stops you from reprinting your own paper.
To prevent some of these excesses, the ACM now has a rule that explicitly allows authors to include ACM papers on the author's own website.
As far as I know, the ACM is the only association that permits this.
Then why do entire lines of CPUs have the same TDP? For example, the Core 2 Duo is 65W across the board from 1.8 GHz to 3 GHz
The entire line has exactly the same TDP because they are exactly the same chip. Intel automatically tests each one as its manufactured, and puts it into the appropriate speed bin. After a while, Intel's manufacturing technology improves, and they actually make too many of the fast chips. At that point, every speed bin gets the same chip. That is why, when the process technology improves, the best overclocking can be done on the slowest chips (provided you can unlock the clock multipliers, and the thermal packaging is identical.) All the chips have the same maximum speed, it is just the slowest ones start at the lowest clock speed.
It used to be, companies would actually produce CMOS chips with speed/voltage/power curves. That was a long time ago. Nowadays, Intel just calls everything 65W in a given line. Nevertheless, the early Asus EeePCs featured an underclocked Celeron processor to reduce power consumption. I recently purchased an AMD desktop processor rated at 45 (W). All the 45 W AMD processors had the lower clock frequencies than their faster AMD siblings. The effect is real. The manufacturers just don't always advertise it anymore.
Also, note that modern semiconductor manufacturing is very complex. AMD actively trades off speed, voltage, power, and fabrication technology to tweak its products for different market segments. This kind of optimization means each chip is specialized. The difference between 45 (W) and 140 (W) is more than just clock speed and voltage. If you increase the voltage on the 45 (W) AMD chip, you might break something. All of these fabrication optimizations make it very difficult to make firm clock speed vs. power dissipation comments. However, as a general trend, it is valid.
Frequency is roughly a cubic effect now. I can purchase either a 45 (W) 2.6 GHz AMD processor, or a 3.2 GHz 125 W AMD processor. I can't purchase a 4 GHz AMD processor, even at 140 (W) plus power dissipations. You can try rerunning the analysis with different models, but every analysis will say that the modern CPU designers have significant power dissipation issues when trying to increase clock frequency to 4 GHz.
This conversation is what's wrong with C++. It is at least two fully independent languages, servicing at least two different interest groups. I'm not sure how relevant either group will be to long-term computing trends, like parallelism. However, first I am going to consider two groups of people that C++ services well.
First, for the low level people, C++ is C with classes. These people want the ability to control every memory allocation and deallocation, although in practice, they only want control over some of them. The low level people use C++ as high-level assembly, and occasionally refer to the assembly print outs. The low level people still don't understand why C++ hasn't fixed it's pointer bug that would make numerical code as fast as FORTRAN. These people know what an interrupt handler is, and may have even written one. Accordingly, RAII and exceptions are explicitly banned from large segments of code.
The second group of people actually use templates and RAII. The big advantage of RAII is that it handles all memory allocation automatically. It brings back the simplicity of the really old (pre-pointer) PASCAL and FORTRAN programs, where everything was allocated on the stack and no memory leaks existed. RAII's big contribution to programming is memory leak-free programming. This second group of programmers, want ease of programming as much as performance. The code they write, makes for very complex assembly. The second group is comparing C++ to languages like C#, Java and Haskell. They are interested in trading off the speed of program writing with the speed of execution.
Some people will quickly point out, that other groups of people may exist. I think a few commercial projects have tried to blend the two extremes. In practice, I think C++ may be too overgrown to be a usable language. If the programmer wants to be safe, use Java. Otherwise, embrace the danger, and do the memory allocs and deallocs are manually, sometimes with custom memory handlers. Use the assembly, as the compilation is being done for speed. However, these are also yesterday's tradeoffs.
Today, parallelism is the new speed optimization. For parallel programming, neither RAII or low-level C++ hacks create a good speed of programming vs. good speed of execution trade off. With multi-CPU, NUMA architectures, the applications need good memory control and multi-processor support. FORTRAN with some of its super-computer extensions is a better language for some of this stuff. Hadoop is uses Java.
Where does C++ sit in this new trade-off? The new standard is silent.
I think you have it backwards. A CPU running at 1 GHz would use 10-20% of the power of a CPU running at 2+ GHz. The modern processor's power consumption is on a cubic power consumption curve. To increase frequency, you have to increase voltage, which gives a 2nd order 1/2 C * V^2 energy loss (per cycle). Additionally, the power consumption is the frequency times the capacitance, so the overall power formula is: 1/2 f * C * V ^ 2 or roughly O(f^3).
Someone more into the physics may be able to give you a better formula. The reason why CPU clock frequencies are not increasing anymore is that increasing frequency dramatically increases power consumption. The semiconductor people really have there backs against some serious technical walls. I wouldn't be expecting CPU power consumption problems to go away anytime soon.
The batteries can take that kind of current, it is just that it wrecks there long-term life span. Simply put, you can charge a battery almost as fast as you can discharge it. 3000 Amps at 96 V may sound like a lot to your average residential home owner, but in the scheme of things, it isn't that much power. It is only 300 kW of power. Most factories have multi-megawatt substations. With 200 A, 240 V residential services (heating usage), it is only about 6 residential homes. The total transformer capacity of a 3 transformer hydro-poll array is probably about 300 kW.
The bigger problem is that you get really fast charge/discharge rates by sizing the charger/motor/battery combination for peak power transfer. This means your efficiency goes through the floor, you abuse the battery, thermal losses increase dramatically, etc. Some schemes define optimal power transfer as the point at which losses equal energy stored. If you implemented this logic, you have created a 300 kW space heater inside your battery, and that can't be good.
Slashdot Mirror
Bell employees call it: "Bell Hell."
My horror stories are endless. They somehow messed up my move, and after 1 year and many many lengthy and repeated phone calls, still were not billing me at the correct address. I finally canceled all my Bell services. It was the only way I could get them to stop billing the wrong address.
Once, someone hacked Bell's backbone routers. All the tech support people would do is go: "We do not support trace route. We do not support trace route. Trace route is not installed on our computers." I finally got them to type in "tracert" at the command line. At that point, they admitted they mysteriously had to leave the phone ... I seem to remember being hung up on, and never getting a call back.
The Bell outgoing email server routinely fucks up. I am pretty sure that they are tweaking the anti-spam settings, and either delete or delay the customer's email messages. Magically, my home internet connection, and all my business customers internet connections, simultaneously loose outbound email for 2 to 3 days. Then it all comes back again. Bell technical support insists the problem is that we use ThunderBird and Microsoft Outlook. Only Microsoft Outlook Express is supported on Bell's network.
Bell Technical Support is so inept: "Bell does not allow them to install any software including Microsoft Outlook Express on there computers." The next time you are trying to debug an email problem with Bell, always remember that you are talking to a person not allowed to use any email software whatsoever. Bell Tech support is only allowed Webmail.
Some of the business types are undoubtedly thinking: Why don't you stop using crappy ADSL lines, and spend $1800/month on a partial T1? Firstly, $1800/month is a significant amount of money to be spending on Internet services, especially in comparison to an $80/month business ADSL line. Secondly, I have spent that much money on fancy Bell Lines. Bell can mess them up too!
Simply put, having ISP's other than Rogers and Bell is vital for Canada's competitiveness. It's called "Bell Hell" for a reason.
It will run better with Windows Vista! and Office too! SQL Server will definitely scale to handle the workload. Some custom .NET programming may be required, but Visual Basic will make it easy. So easy that anyone can do it. No problems.
Check out the terms of service on your bank account. You might be shocked to learn the bank isn't responsible for your financial losses. Often, they specifically exempt themselves from all responsibility relating to fraud, mistakes, and/or computer errors. If they cash a bad cheque, you are on the hook.
There is a reason why people that survived the Great Depression hide money under their mattresses.
You nailed the comment in 6 words.
I've been to Northern Canada. A compass points to MAGNETIC North. True North is at the North pole, the point on which the earth spins. At true north, the sun never sets, and sometimes never rises for days on end. In summer, it has the longest days in the world. In winter, the longest nights. Magnetic north is not the same place at all ...
Magnetic North has some interesting properties too. Amongst others, the Magnetic south and north poles move around, periodically flip, and do not pass through the center of the earth.
In general, USB Serial under Windows is horrible. Windows XP has many USB serial ports with buggy drivers. Most devices that I tested had either data corruption issues, or simply wouldn't do high baud rates, or both. If you use the FTDI chipset based devices, then at least no data corruption occurs at high baud rates. All of the drivers that I used would fail if the USB device was disconnected while RS-232 communication was occurring, and then reconnected again. To recover, Windows XP either had to be rebooted, or the USB port reassigned to a different COM port number. A reboot for a USB driver???
Also, many older specialty programs won't work with USB serial ports. Essentially, Microsoft slightly changed the behavior of the polled mode ReadFile/WriteFile calls, so USB serial ports behave differently than built-in serial ports. This breaks old software.
USB serial ports under Windows for antiquated embedded / real-time applications can be a real nightmare. The only success I had at high baud rates was with the FTDI chipset and drivers. Even they, broke old software, and required a reboot if the USB device was unplugged during communications.
And you are worried about Linux driver support? I'm pretty sure that this is one of those cases where Linux works better than Windows.
Catching a submarine ... that would be the ultimate fish story!
Go for the obvious. Someone is trying to get revenge on corporation "x" by purchasing a bunch of computers and having them drop shipped. By the time accounting catches up with the paperwork, the computers will be in the hands of the FBI for a month. If the scam is done right, it is done by an ex-employee or someone with just enough access to know who the preferred suppliers are. You make a couple of phone calls, send the right paperwork, and next thing your computer vendor is drop shipping a bunch of computers somewhere.
Having worked for distributors, I'm surprised this doesn't happen more often. Having stuff go missing for weeks on end inside factories, fairly routine ... This wouldn't be hard to do. Just ship a bunch of computers somewhere else.
It is even difficult to get charged for doing something like this. FAXing the paperwork leaves no fingerprints. To the accounting department, the transaction looks like typical incompetence. The corporation won't request charges laid, because then they would have to admit they were incompetent too, and this stuff happens all the time. The police have a tough time charging you, because you didn't steal anything. If done right, you didn't even touch anything so there is no physical evidence. No evidence means no crime, and your revenge makes the national newspapers. Perfect revenge scheme.
Actually, I thought about your point when the show aired. In fact, it is impossible for that planet to exist. You can't form a long-term stable orbit around a black hole. From a two-body, Newtonian point-mass analysis, yes the planet can exist. However, a planet that close to a black hole will be affected by Einstein's General Relativity, which predicts a collapsing orbit. Additionally, the planet would be experiencing severe gravitational stresses and magnetic stresses, causing it to break up or its orbit to decay. The other matter collapsing into the black hole would disrupt the "stable" orbit, also causing the planet's orbit to decay or it to break up. In short, I don't think that it is possible to have a long-term stable orbit around an black hole when it is consuming matter.
If you want a bigger plot "hole", think about where the magic gravity beam came from. Why would it come from a black hole? If it came from the planet, then why was it pointed in space? If the evil creature could create a gravity beam big enough to save a planet, then why couldn't he make a slightly bigger one and take over the universe? Maybe, we need to accept that any Sci-Fi plot will have its weak points, and suspend our disbelief.
The Satan Pit / Impossible Pit were really great Doctor Who episodes. Maybe we should appreciate them for that, instead of taking apart the physics?
I just finished looking at a paper on the subject from 1972. In 1972, wrist watches were already using special bipolar transistor circuits for low power consumption. Standard TTL was unsuitable for the application. There was already a widespread drive to switch to CMOS, starting with RCA in 1967.
The first early LSI watch chip was an Intel 5810 CMOS chip, and it is likely that is the chip in your 1979 LED wrist watch. Specifically, the Intel prototype boards used LEDs as the display for this chip.
Given the chip comes from Intel, the inventors of the 4004, it is likely that there are at least some subtle design queues taken from the other Intel products. Simply put, the architecture of a wrist watch design, specifically the multiplexed displays, really lends itself to a certain type of solution that resembles a computer design. A central data bus connecting the registers/counters saves transistors in the overall design.
Most of those old digital watch chips used a surprisingly microprocessorish architecture, and MOS (maybe even CMOS). I can almost guarantee that chip was not done with standard TTL, or even LSTTL. Your watch probably borrows from the 4004 type pre-computer architectures floating around at the time.
There are two big reasons why a standard TTL architecture is not the way to go. Firstly, TTL consumes a great deal of power, which isn't optimal for a watch.
The second reason to use a CPU-style architecture is that the LCD and/or LED (for really old digital watches) displays are multiplexed. You could build a full multiplexer to drive the displays, or your could use a data-bus like architecture. Once you have a databus, then it becomes a question of how you want to increment/decrement the counters, and if a central 4-bit adder is better than a series of counter chains floating around the chip. Either way, the counters are going to be registers, and the data will be multiplexed on the data bus to drive the LCDs. For programming, several AND-OR logic circuits are required to do the BCD counting arithmetic, the BCD to seven segment decode functions, and the function sequencing. We could discuss if the design merits the full "programmed CPU" designation, but the design will have enough stuff to look surprisingly like an early computer/counting machine/calculator design.
It sounds like Chicago's system is significantly worse than Toronto's. In Toronto, those meter boxes are everywhere. In Chicago, I think they put in many fewer meter boxes. Also, the boxes that Toronto does use, can be scammed. The boxes are also a pain when the Credit Card slot stops working / freezes in the winter, then you need more change than any normal human carries around.
Also, Toronto's rates for parking are much lower. I haven't heard of having to pay $84 for parking for anywhere in Toronto.
I'm not sure IBM Mainframe's count as POS systems. However, you are correct in that large numbers of these applications are terminal applications running on a mainframe. At first, dedicated terminals were used. Then, they switched to DOS based PCs. My bank has used both OS/2 and Windows based PCs more recently. Still the same green screen applications, however now some of them have better user interfaces.
I think it really depends on your approach. If you look at it like an embedded systems person, you are looking at the OS and technologies put into all the little small devices. I work more with machine controllers than POS systems, and they are all networks of small (or bigger) microprocessors and microcontrollers. Each device takes on a different section of the job to make parts emerge from the factory.
If you approach the systems from a datbase/big systems/accounting point of view, then you see the IBM mainframe, or the UNIX/AIX central system, or more recently some type of SQL Database. It all really depends on your area of interest.
For instance, people talk about PCs in cars. The embedded people know that the average car today is shipping with at least 4 different microcontrollers (Radio, Engine, Transmission, Body Control (Door Locks), and/or Air Bags.) For the embedded people. the computer revolution happened a long time ago. Every person has a different perspective.
The embedded market is known for its fondness of cheap hardware, and sticking to the status quo. For many years, DOS was a dominant O/S for Point of Sale applications. In recent years, Windows is getting more popular. Linux is a big portion of this market, because it is free, and has real-time extensions. You can control entire machine tools in real-time with Linux, implementing the servo-loops on a PC in software. You can even prototype embedded applications, like motor controllers, in real-time Linux on a PC, and then port to an appropriately sized embedded platform when you know your processor requirements. With embedded PC chips, like these, it may not even be cost effective to switch off the PC platform for some applications.
The 68000 / ColdFire line is getting rather old at this point. The problem is that only two platforms long-term can keep up the pace with the cost of modern processor development. The IBM Power series (including the cell for the PS3), and the Intel/AMD x86 platform. Everyone else, cannot keep up with the cost of modern processor development and the cost of fabrication facilities. Even AMD struggles to finance fabrication, with the resulting Global Foundaries spin-off. Intel struggles with the same problem too. Intel is unable to make the Itanium (Itanic) line competitive with the x86 line. The top 10 supercomputers are all either Power series processors, x86 AMD or x86 Intel. On the total Top 500 list, only a very few systems (6) use Intel Itanium. It simply costs too much money to develop a processor architecture, and only the largest architectures can remain competitive on a cost/performance basis.
There are many simple embedded applications that do use inexpensive processors. There is an entire industry developing 8-bit, 16-bit, and even some 32-bit embedded processors (including the ColdFire.) However, generally the PC is not competing in the same space. Interfacing between the 8-bit processors and the PC is becoming a challenge.
Does anyone know good ways to connect the embedded processor to a standard PC motherboard? RS-232 is becoming rare. Ethernet overwhelms the small processors with data. Any good embedded communication solutions for networked motor drive and control applications?
When you count pennies, dimes are an order-of-magnitude. Reducing the memory usage from 91K to 41K could be a micro-controller versus a micro-processor and external memory. It could be the difference between a chip that costs $11 and one that costs $8. When you are trying to find ways of eliminating 1 cent capacitors, eliminating chips represents big dollars. The embedded people think about things differently.
Linksys rewrote changed the entire software stack for the WRT54GL. They even switched operating systems, simply to halve the number of memory chips in the design.
For some embedded applications, a program size of 90kb to 41kb would result in a very large Christmas Bonus. It would be considered an order-of-magnitude reduction, and you would be a hero.
Fortran is a much older language than C++, and it supports variable sized arrays with known sizes in calling functions. It is also one of the few languages that are faster than C on supercomputer number crunching applications.
C++ should be several different languages, that can be compiled and linked together. The source files should have DEFCON levels to show how dangerous / fast they are.
DEFCON 5 - Peace. The most passive Java/Python/Scriptish code imaginable; run-time types; and built-in automatic memory management.
DEFCON 4 - Forces compile-time type checking.
DEFCON 3 - Adds Multi-processing / Cluster computing.
DEFCON 2 - Fast code; direct access to all member variables; none of the get/put call slowness; memory management is banned (no new or delete); and no aliased variables. Numerical code as fast as Fortran. Code automatically configured to work well with MPI / Cluster configurations.
DEFCON 1 - Pointers. Manual memory management.
With DEFCON levels on the source files, bugs can be contained to areas of code, and the class/optimization level of the code can become clearly visible.
Late with your homework assignment, again?
Yes, Minister and Yes, Prime Minister were intended to be satirical comedies.
In Canada, every new MP in Ottawa is told to watch them on there first day. "Just to get an idea of how things actually work ..."
The practical problem is that either:
a) Warp Drive is possible. In which case, there is probably some sort of faster than light communications protocol too. In which case, we just are not in the fast lane. Chances are, if someone was using Warp Drive and Faster than Light communications, we would never notice, because we know nothing about the technology. Space is also big. They may not have bothered to find us, or they might have no reason to talk to us.
b) Warp Drive is impossible. In this case, the energy budget of even traveling with small probes at 0.1c would be so huge, that it is unlikely anyone would find us. Even if a 100 million year old probe was sitting in this solar system, do you think we would find it?
Either way, space is big, we are small. Unless we have a breakthrough, we are not going anywhere.
That is the way it works. If you include colour graphics, then many journals require payment before publishing your paper. In that case, you need to pay for the conference, and pay for the paper. In return the journal keeps your copyright, and stops you from reprinting your own paper.
To prevent some of these excesses, the ACM now has a rule that explicitly allows authors to include ACM papers on the author's own website. As far as I know, the ACM is the only association that permits this.
The entire line has exactly the same TDP because they are exactly the same chip. Intel automatically tests each one as its manufactured, and puts it into the appropriate speed bin. After a while, Intel's manufacturing technology improves, and they actually make too many of the fast chips. At that point, every speed bin gets the same chip. That is why, when the process technology improves, the best overclocking can be done on the slowest chips (provided you can unlock the clock multipliers, and the thermal packaging is identical.) All the chips have the same maximum speed, it is just the slowest ones start at the lowest clock speed.
It used to be, companies would actually produce CMOS chips with speed/voltage/power curves. That was a long time ago. Nowadays, Intel just calls everything 65W in a given line. Nevertheless, the early Asus EeePCs featured an underclocked Celeron processor to reduce power consumption. I recently purchased an AMD desktop processor rated at 45 (W). All the 45 W AMD processors had the lower clock frequencies than their faster AMD siblings. The effect is real. The manufacturers just don't always advertise it anymore.
Also, note that modern semiconductor manufacturing is very complex. AMD actively trades off speed, voltage, power, and fabrication technology to tweak its products for different market segments. This kind of optimization means each chip is specialized. The difference between 45 (W) and 140 (W) is more than just clock speed and voltage. If you increase the voltage on the 45 (W) AMD chip, you might break something. All of these fabrication optimizations make it very difficult to make firm clock speed vs. power dissipation comments. However, as a general trend, it is valid.
Frequency is roughly a cubic effect now. I can purchase either a 45 (W) 2.6 GHz AMD processor, or a 3.2 GHz 125 W AMD processor. I can't purchase a 4 GHz AMD processor, even at 140 (W) plus power dissipations. You can try rerunning the analysis with different models, but every analysis will say that the modern CPU designers have significant power dissipation issues when trying to increase clock frequency to 4 GHz.
This conversation is what's wrong with C++. It is at least two fully independent languages, servicing at least two different interest groups. I'm not sure how relevant either group will be to long-term computing trends, like parallelism. However, first I am going to consider two groups of people that C++ services well.
First, for the low level people, C++ is C with classes. These people want the ability to control every memory allocation and deallocation, although in practice, they only want control over some of them. The low level people use C++ as high-level assembly, and occasionally refer to the assembly print outs. The low level people still don't understand why C++ hasn't fixed it's pointer bug that would make numerical code as fast as FORTRAN. These people know what an interrupt handler is, and may have even written one. Accordingly, RAII and exceptions are explicitly banned from large segments of code.
The second group of people actually use templates and RAII. The big advantage of RAII is that it handles all memory allocation automatically. It brings back the simplicity of the really old (pre-pointer) PASCAL and FORTRAN programs, where everything was allocated on the stack and no memory leaks existed. RAII's big contribution to programming is memory leak-free programming. This second group of programmers, want ease of programming as much as performance. The code they write, makes for very complex assembly. The second group is comparing C++ to languages like C#, Java and Haskell. They are interested in trading off the speed of program writing with the speed of execution.
Some people will quickly point out, that other groups of people may exist. I think a few commercial projects have tried to blend the two extremes. In practice, I think C++ may be too overgrown to be a usable language. If the programmer wants to be safe, use Java. Otherwise, embrace the danger, and do the memory allocs and deallocs are manually, sometimes with custom memory handlers. Use the assembly, as the compilation is being done for speed. However, these are also yesterday's tradeoffs.
Today, parallelism is the new speed optimization. For parallel programming, neither RAII or low-level C++ hacks create a good speed of programming vs. good speed of execution trade off. With multi-CPU, NUMA architectures, the applications need good memory control and multi-processor support. FORTRAN with some of its super-computer extensions is a better language for some of this stuff. Hadoop is uses Java.
Where does C++ sit in this new trade-off? The new standard is silent.
I think you have it backwards. A CPU running at 1 GHz would use 10-20% of the power of a CPU running at 2+ GHz. The modern processor's power consumption is on a cubic power consumption curve. To increase frequency, you have to increase voltage, which gives a 2nd order 1/2 C * V^2 energy loss (per cycle). Additionally, the power consumption is the frequency times the capacitance, so the overall power formula is: 1/2 f * C * V ^ 2 or roughly O(f^3).
Someone more into the physics may be able to give you a better formula. The reason why CPU clock frequencies are not increasing anymore is that increasing frequency dramatically increases power consumption. The semiconductor people really have there backs against some serious technical walls. I wouldn't be expecting CPU power consumption problems to go away anytime soon.
The batteries can take that kind of current, it is just that it wrecks there long-term life span. Simply put, you can charge a battery almost as fast as you can discharge it. 3000 Amps at 96 V may sound like a lot to your average residential home owner, but in the scheme of things, it isn't that much power. It is only 300 kW of power. Most factories have multi-megawatt substations. With 200 A, 240 V residential services (heating usage), it is only about 6 residential homes. The total transformer capacity of a 3 transformer hydro-poll array is probably about 300 kW.
The bigger problem is that you get really fast charge/discharge rates by sizing the charger/motor/battery combination for peak power transfer. This means your efficiency goes through the floor, you abuse the battery, thermal losses increase dramatically, etc. Some schemes define optimal power transfer as the point at which losses equal energy stored. If you implemented this logic, you have created a 300 kW space heater inside your battery, and that can't be good.