I need to find some real applications with below assumptions:
We have several processes (either on the same machine, or distributed) that can communicate with each other
A time unit has T seconds. We have this global time accessible in each process.
At each T seconds the global time increases with one unit. Only the current time unit has a global data zone where processes can read/write.
Thanks !
It sounds like you need a Real-Time Operating System (RTOS). You may find RTLinux to be a useful operating system. You may also want to check these two hyperlinks.
Related
If I were to write a program and I wanted to be guaranteed that the program never sees an instance where, after it is running, it gets kicked off of the cpu until program termination, would I need an RTOS or is there a way to have such an experience guranteed on a regular linux os.
Example:
Lets say we a running a headless Linux machine and running a program as user or root (eg reading SPI data from a sensor, listening for http requests) and there is reason to believe there is almost almost no other interaction with the machine aside from the single standalone script running.
If I wanted to ensure that my process running never gets taken off my cpu even for a moment such that I never miss valuable sensor information or incoming http requests, does this warrant a real-time operating system to keep this guarantee?
are process priorities of programs ran by the user / root enough of a priority to not get kicked off?
is a realtime os needed to guarantee our program never witnesses a moment when it is kicked off of the cpu?
I know that Real Time OS are needed for guarantees on hard limits and hard deadlines of events. I also know that on a regular operating system it is up to the OS to decide priority and scheduling.
if this is in the wrong stack let me know.
Do you need to act on sensor readings in a constant time frame? How complicated this action should be? If all you need is to never miss a reading and you're ok with buffering them - just add a microcontroller or an FPGA in between your non-realtime device and a sensor.
Also, you can ensure some soft real time constraints even with an unpatched Linux. You can pin a process to a CPU and avoid using any syscalls in it - spin and poll instead, at 100% CPU utilisation, and then it's likely kernel will never touch it. Make sure the process binary and all the dynamic libraries (if any) are on a RAM disk (to avoid paging) and disable swap.
Till now I was doing load/performance testing (load runner & jMeter) on my local instance(connected to LAN not over wifi) and I was sure about the results. But now I have to do it Virtual desktop infrastructure (VDI). Does it provide the same result as the local instance? Or is it good practice to perform the tests over the VDI?
LoadRunner or JMeter don't care about underlying hardware as you have at least 2 abstraction layers: operating system and C and/or Java runtime.
So given your VDI has the same hardware specifications - you should be getting the same results for the same test in terms of delivered load. I would however recommend monitoring your VDI main health metrics, like CPU load, RAM and Pagefile usage, Network and Disk IO, etc.
In the majority of cases VDIs don't have fully dedicated resources, i.e. if you see 64GB of RAM it is not guaranteed you can allocate them all as the RAM may be shared between other VDIs on hypervisor level.
So monitor your load generator(s) system resources usage and make sure you have enough headroom for running your load tests. See How to Monitor Your Server Health & Performance During a JMeter Load Test guide for more details.
Use a physical load generator as a control element. Run single virtual users of each type on the physical box. If you see that your control group begins to take on different performance characteristics (slower, higher degrees of variance as measured by standard deviation, higher averages, 90th percentiles and maximums) then you have a case for maintaining some physical infrastructure for testing.
The biggest issue directly attacking timing record integrity inside of virtualized load generators is clock jump. The system clock in the virtualized host floats slower with respect to the physical clock on the hardware. Occasionally this needs to be re-synched, causing time to jump. Inevitably this happens while the timing record is open and causes what appears to be a long timing record. Some people suggest that this doesn't happen until you start to see backups in the CPU queue length, which is somewhere in the 75-80% CPU range. I have seen it at even as low as 10% of CPU, because under those light loads the hypervisor can make decisions to parse resources to higher need virtualized instances and then when you get the CPU token back it is time to jump the clock.
The control load generator provides a check against this behavior. If necessary you can even use the control load generator in a statistical sampling model along the lines of manufacturing quality control. You can also show objectively to anyone demanding you move to a virtualized model what the impact of this change will be on the integrity of the response time samples collected.
It depends on the VDI. Is it on same network as your localhost?
If it is, the result would be almost same (depends on configuration of VDI too, very minimal overheads that we might not even notice though)
If it is not, the result would depend on how good is that network.
We know that in bash, time foo will tell us how long a command foo takes to execute. But there is so much variability, depending on unrelated factors including what else is running on the machine at the time. It seems like there should be some deterministic way of measuring how long a program takes to run. Number of processor cycles, perhaps? Number of pipeline stages?
Is there a way to do this, or if not, to at least get a more meaningful time measurement?
You've stumbled into a problem that's (much) harder than it appears. The performance of a program is absolutely connected to the current state of the machine in which it is running. This includes, but is not limited to:
The contents of all CPU caches.
The current contents of system memory, including any disk caching.
Any other processes running on the machine and the resources they're currently using.
The scheduling decisions the OS makes about where and when to run your program.
...the list goes on and on.
If you want a truly repeatable benchmark, you'll have to take explicit steps to control for all of the above. This means flushing caches, removing interference from other programs, and controlling how your job gets run. This isn't an easy task, by any means.
The good news is that, depending on what you're looking for, you might be able to get away with something less rigorous. If you run the job on your regular workload and it produces results in a good amount of time, then that might be all that you need.
There are many online judge sites which can verify your program by comparing its output to the correct answers. What's more, they also check the running time to make sure that your program running time doesn't exceed the maximum limit.
So here is my question, since some online judge sites run several test programs at the same time, how do they achieve performance isolation, i.e., how can they make sure that a user program running in a heavy-loaded environment will finish within the same time, as when it is running in an idle environment?
Operating systems keep track of CPU time separately from real-world "wall clock" time. It's very common when benchmarking to only look at one or the other kind of time. CPU or file I/O intensive tasks can be measured with just CPU time. Tasks that require external resources, like querying a remote database, are best measured in wall clock time because you don't have access to the CPU time on the remote resource.
If a judging site is just comparing CPU times of different tests, the site can run many tests simultaneously. On the other hand, if wall clock times matter, then the site must either use independent hardware or a job queue that ensures one test finishes before the next starts.
As The Computer Language Benchmarks Game measures both CPU time and Elapsed time those measurements are made sequentially in an idle environment.
For some of the customers that we develop software for, we are required to "guarantee" a certain amount of spare resources (memory, disk space, CPU). Memory and disk space are simple, but CPU is a bit more difficult.
One technique that we have used is to create a process that consumes a guaranteed amount of CPU time (say 2.5 seconds every 5 seconds). We run this process at highest priority in order to guarantee that it runs and consumes all of its required CPU cycles.
If our normal applications are able to run at an acceptable level of performance and can pass all of their functionality tests while the spare time process is running as well, then we "assume" that we have met our commitment for spare CPU time.
I'm sure that there are other techniques for doing the same thing, and would like to learn about them.
So this may not be exactly the answer you're looking for, but if all you want to do is make sure your application doesn't exceed certain limits on resource consumption and you're running on linux you can customize /etc/security/limits.con (may be different file on your distro of choice) to force the limits on a particular user and only run the process under that user. This is of course assuming that you have that level of control on your client's production environment.
If I understand correctly, your concern is wether the application also runs while a given percentage of the processing power is not available.
The most incontrovertible approach is to use underpowered hardware for your testing. If the processor in your setup allows you to, you can downclock it online. The Linux kernel gives you an easy interface for doing this, see /sys/devices/system/cpu/cpu0/cpufreq/. There is also a bunch of GUI applications for this available.
If your processor isn't capable of changing clock speed online, you can do it the hard way and select a smaller multiplier in your BIOS.
I think you get the idea. If it runs on 1600 Mhz instead of 2400 Mhz, you can guarantee 33% of spare CPU time.
SAR is a standard *nix process that collects information about the operational use of system resources. It also has a command line tool that allows you to create various reports, and it's common for the data to be persisted in a database.
With a multi-core/processor system you could use Affinity to your advantage.