Tag Info

New answers tagged

0

Ostinato looks to be one such tool that you're looking for. Ostinato is an open-source, cross-platform network packet crafter/traffic generator and analyzer with a friendly GUI. Craft and send packets of several streams with different protocols at different rates. Screenshot      Screencast Ostinato Packet/Traffic Generator ...


1

See discussion at Can I configure my Linux system for more aggressive file system caching? In short, you probably need to have to tune some device queue settings. I'd guess scheduler or queue setting is incorrectly guessed by kernel or manually set. Try head /sys/block/sd*/{queue/{nr_requests,nomerges,rotational,scheduler},device/queue_depth} to debug ...


0

You can to try use the timeit module, available in any system with Python: $ python -m timeit "__import__('os').system('my comand here')" 10 loops, best of 3: 591 msec per loop


4

Call time myprogram. This reports wall clock time, user time and system time. User time is the time spent by the process in computations. If the program is multithreaded and the machine has multiple processors, the time spent on all processors is summed (so for a sufficiently parallel program, the user time can be more than the wall clock time). The system ...


-1

Now that I look again, I realized you said this was a usb key ( flash drive ) not a hard drive. Flash memory can only be erased in large blocks, and individual sectors can not be written without erasing them ( and the whole block they are in ) first. Since software expects to be able to write wherever it wants on the disk at any time, the disk has ...


3

If you can get the pid, which shouldn't be hard with either ps, /proc/self or $! depending on whether or not you background it you can find this in: /proc/$pid/stat: utime %lu (14) Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by ...


-1

This happens due to the optimization of writing Sparse files in filesystem. When you do dd if=/dev/zero to raw device, the zero blocks are actually written to disk. However when you write them to a file, the filesystem ignores writing the data and saves just the metadata. This results in very few blocks being written to disk. The file can be seen as a big ...


0

Try using hdparm instead to benchmark a drives performance with and without using any caching: $ sudo hdparm -tT /dev/sda1 /dev/sda1: Timing cached reads: 6314 MB in 2.00 seconds = 3157.61 MB/sec Timing buffered disk reads: 244 MB in 3.04 seconds = 80.26 MB/sec


0

Your measurement results can be explained with the kernel architecture. Using filesystem access will unlease the full potential of the kernel with all buffers and optimizations that it can do. Especially the buffers will speed up your benchmark (b/c the kernel is 100% a_A_syncronous). dd on a device file does not use any/much of this.


1

The answer that isn't really an answer: For those following along at home, you'll noticed I've had a heck of a time trying to get kSar to do this for me. I don't doubt that there actually is a solution with kSar but I've come to the hard earned conclusion that kSar just kind of sucks. I don't work with non-Linux platforms anymore (used to manage Solaris, not ...


1

While I’ve never tried doing what you are doing, the best way to do this with OpenBSD will likely be with tables as you can easy add/remove IPs from tables.


23

Apart from not getting detailed information about your test setup the main problem seems to be, that you use a message size of 64 byte. This is far away from the usual MTU of 1500 bytes and makes UDP highly inefficient: while TCP merges multiple sends into a single packet on the wire (except if TCP_NODELAY is set) to make efficient use of the link, each UDP ...


9

On the one hand, the first method calls tail twice, so it has to do more work than the second method which only does this once. On the other hand, the second method has to copy the data into the shell and then back out, so it has to do more work than the first version where tail is directly piped into grep. The first method has an extra advantage on a ...


3

I think the main difference is very simply that echo is slow. Consider this: $ time (tail -n 1000000 foo | grep 'true' | wc -l; tail -n 1000000 foo | grep 'false' | wc -l;) 666666 333333 real 0m0.999s user 0m1.056s sys 0m0.136s $ time (log=$(tail -n 1000000 foo); echo "$log" | grep 'true' | wc -l; ...


3

I had a go at this as well... First, I built the file: printf '"success": "true" "success": "true" "success": "false" %.0b' `seq 1 500000` >|/tmp/log If you run the above yourself, you should come up with 1.5million lines in /tmp/log with 2:1 ratio of "success": "true" lines to "success": "false" lines. The next thing I did was ...


26

I've done the following test and on my system the resulting difference is about 100 times longer for the second script. My file is a strace output called bigfile $ wc -l bigfile.log 1617000 bigfile.log Scripts xtian@clafujiu:~/tmp$ cat p1.sh tail -n 1000000 bigfile.log | grep '"success": true' | wc -l tail -n 1000000 bigfile.log | grep '"success": ...


5

Actually the first solution reads the file into memory, too! This is called caching and is automatically done by the operating system. And as already correctly explained by mikeserv the first solution exectutes grep while the file is being read whereas the second solution executes it after the file has been read by tail. So the first solution is faster ...



Top 50 recent answers are included