- measurement at thread level (top and the like) should report
instructions retired per unit of time, not %CPU.
We want to know how much work is being done.
The explanation on why so much/so little requires more information
(scheduler? cache misses? cpu throttling?)
- measurement at the CPU level (mpstat, etc) should report
both %CPU (as "time active" vs "wall clock time") and
active clock cycles per unit of time
(dividing by clock stretching factor if used, and
perhaps scaled to absolute max frequency and/or %CPU
if one wants a percentage).
%CPU tells us whether we are making full use of the available time,
and perhaps suggests to schedule threads differently if appropriate
Clock cycles tell us how much one CPU is affected by throttling
(manual, automatic, due to C-state exits, etc), and this is an orthogonal
indication on whether there is something at the system level that is
making the CPU underutilized
>> "With so many people and students around the world working from home, we really need some easy to deploy shared whiteboard solution. This is especially important for pre-college students who may not have access to high end hardware."
>Just add a new mode to videoconferencing, where both parties get a white screen and both can start drawing and the resulting image stays in sync on both clients? (I feel like this solution is so obvious, I'm about to fly out a window - what am I missing?)
Author here.
There have been a few proposals in this space for the past 25 years including hangouts extensions, using a virtual camera that just exports the screen (if people remember the old mbone tools wb and vic; I myself wrote an extension to replace the camera with a snapshot from a configurable region of the X screen), and my own shared whiteboard which gives parties a shared screen that they can edit modify replay ...
There are two main reasons (in my opinion) why this space has been neglected:
- almost nothing matches the convenience, speed and _resolution_ of writing and drawing with an actual pen.
Pads with sufficient resolution and decent lag are only appearing now, and they are fragile and expensive.
Graphic tablets are cheap but lack the visual feedback and looking at the output on the screen still has significant latency.
They are moderately usable, but takes time to get used to them, and you need a real 10+in screen to use them effectively.
Using a finger or a conductive pen on a phone screen is only good for small sketches, not for writing longer sentences or formulas.
- the main users of such products would be non commercial entities (pre-college schools, students) so there are no paying customers.
Even at college level lectures are increasingly based on slides prepared in advance. Businesses, of course, use slides or meet in person, and the whiteboard style of collaboration is generally done in person.
Social distancing now may actually create more use cases and perhaps returns (in terms of actual money or social appreciation) that stimulate software solutions to appear.
The Apollo13 problem still stands: even if we had good and cheap technology for writing, at this time it would be impossible to build and sell such products to customers, so we have to find solutions that use hardware already in possession of the users.
(I have a similar Javascript configuration for Spectacle, I can post it if there is interest. I believe the javascript is easily portable to other scriptable window managers.)
My rationale for developing lrtile is the following:
I like having window corners on a grid because it helps locating information.
However, in many tiled WMs, resizing one window causes resizing of nearby ones (very distracting) _and_ windows generally do not overlap (a severe limitation especially on small screen). Finally, shortcuts to place windows on half or a quarter of the screen are often built-in (in chrome, windows, spectacle default...) but very few WMs have larger, configurable grids suitable for large monitors (I use a 40" 4K screen).
lrtile addresses the above problems as follows:
- the grid is configurable;
- movement/resize only affect the current window, allowing overlap if user wants;
- commands are arrows + 1/2 modifiers, and try to be intuitive
- screen borders act as hard stops, also making behavior more intuitive.
In detail, I typically use a 6x6 grid on small screens (so I can have halves or thirds) and 12x10 or even bigger on large screens. Each window side must be at least two units, and resize extends or reduces one dimension at a time and by one unit.
My typical workflow is to make windows visible with a comfortable size and no overlap, and occasionally expand the window I care about (e.g. make the browser wider when a page does not render well; or expand the editor window vertically when I want to see a larger chunk of code), reverting back when done. The fact that move and resize commands are very similar to other cursor movements makes the operation very quick.
I have been using Spectacle for ages (with a custom javascript config, another post...).
The problem is, Spectacle uses a 32bit API that is scheduled to go away and I am afraid that at some point (or 10.15 already?) it will stop working.
Of all the problems you can have with this setting, brightness is not one of them.
I have been using 4k 40" tvs and monitors with OSX and FreeBSD/linux for over 2 years now and overall I am quite happy with the choice.
I wouldn't go much above 40", as it would involve too much head movement (while sitting at least, I find myself comfortably using only 2/3 of the height).
One annoying problem especially with older or low end TVs was definitely lag. Even after disabling all "picture enhancements" and setting the equivalent of gaming mode, many TVs in 2014-2015 had high lag, from the 120ms that even Samsung/LG were showing, up to the 300+ms of Seiki and Haier and other no-name TVs. That makes the monitor unusable even for text editing. From personal experience, 2016 Samsung at least are much better, but better try them before buying.
Next comes viewing angle and color -- cheap panels have a limited vertical viewing angle, and sometimes even limited color depth.
Then you have to fight with OS and applications. For some combinations of OSX and TVs, I had the OS applying non-removable overscan after identifying the screen as a TV. OSX also does antialiasing which results in blurred characters with small fonts in terminals. I haven't found a good bitmapped font to use.
Apps also have problems, e.g. chrome on OSX does not refresh well the bottom bar when you move windows between the 4k and the retina screen. Or, some video players fail to go full screen on 4k.
(OP/author here) I think you should have asked before changing the URL.
The original URL pointed to the correct repository and had up to date performance numbers. Now it only points to the paper which is has stale information on both. Any chance to restore the original ?
I really don't understand why for this use case people do not use a third wheel and save the energy consumed to stand still with self balancing.
Not just this segway, also the double robot (the latter, at least, can claim aesthetic motivations given the barrel shape).
(netmap author here)
I prefer to define netmap as a "network stack bypass" scheme because we use as much as possible of the OS -- all the things it does well, we do not want to reinvent. Device drivers, system calls, synchronization support etc. are part of the kernel. Native netmap support for a NIC only involves 3-400 lines of code, or 10% of the typical device driver.
Processes do ioctl(), mmap() and poll() for I/O - all standard system calls implemented by the OS, there is no NIC-specific code in the application. NICs can be switched in and out of netmap mode without reloading modules (and with the cloudflare patch, even sharing the two modes). There are no custom memory pools or hugepages to reserve. Device configuration relies on ethtool and ifconfig etc.
This approach is what let the cloudflare folks implement their traffic steering with zero new code, just a couple of ethtool lines; the change they contributed back to support the split mode is completely agnostic of the specific NIC being used.
Speaking of screen size, having used it i confirm that 39-40" is what i find the minimum acceptable size for 4K if you are not running in HiDPI mode. It corresponds to 1080p at 20" which (which to my 50y eyes is almost below the threshold of what i can see).
I have tried 4K@30Hz using HDMI on five different TVs (not monitors): Seiki 39" US, Seiki 39" UK (US and UK modes are different), Hisense 42K680, Samsung UE40HU6900DX, LG 40UB800 (the latter three are in Italy and seem available across europe).
In all cases the additional display lag wrt my retina MBpro screen (measured with the small HTML/JS at the end) was huge, in the 130-230ms range, i.e. 4-7 frames. As a comparison, even the low end 1080p TVs i tried (at 60Hz) only gave 0-16ms additional lag, i.e. one frame.
The problem is not 30Hz vs 60Hz, but a video pipeline which is too deep, and cannot be shortened in any of the models i tried (even the models that have a "gaming" mode disable that control when running at 4k).
Note that even at 30Hz one frame is only 33ms so anything more than 66ms indicates excessive pipeline depth.
Based on my measurements, I think that at the moment the chipset that do 4k (upscaler etc.) are still buggy/immature in terms of features, and probably we need to wait the next generationof silicon to get 4K TVs that can be used as monitors.
I have become used to the 130ms lag but it is not pleasant.
Note that the Acer Chromebook C720 ($199) can drive the screen at 4K through the HDMI port. I had no problem with FreeBSD using high end nvidia cards (GT640 and GT750), whereas lower model seem unable to use pixel clocks above 165 MHz (you need about 290 MHz to run at 4k).
<!DOCTYPE html><html><head><script>
Object.prototype.d = function(l) {
return (this + Math.pow(10,l)).toString().substring(1, l+1) }
function g(x) { return document.getElementById(x); }
function clock() {
var t=new Date();
g('txt').innerHTML=t.getSeconds().d(2)+'.'+t.getMilliseconds().d(3);
setTimeout(clock,1);
}
</script></head>
<body
Set PC to mirror screens, take a snapshot with a camera, compare times<br/>
<div id="txt" style="font-size: 120px;"></div>
</body></html>
I can't comment on HFT because I have no experience on that, and their focus is latency rather than throughput.
For the latter (which matters in routers, for instance), netmap runs on everything (either natively or with some emulation). The intel 10g cards (which DPDK of course supports) are around 3-400$ i think, the 1G cards start around a few 10's of dollars (not that you need userspace networking at 1G).
netsend and other apps used in that comparison were not rate limited. Surely that test only measures system's overheads, but i put that disclaimer very clearly in all papers and talks (btw "which it isn't" suggests that you have different numbers so please let us know). Surely, sometimes these per-packet savings are irrelevant, but there are a number of use cases where this kind of savings matter a lot. This is true for netmap, dpdk, DNA and all other network-stack-bypass frameworks.
On passing, people typically use the term 'os-bypass' but netmap relies on the OS for protection, synchronization, memory management etc -- all things that the OS does well and i find no reason to reinvent.
I really wish i could find a use for the chromebooks for my family, but i failed. This one seems similar to the samsung chromebook, which i tried for a while (also lending it to mother, sister, children) but we all found it basically useless for any everyday task.
Surely one can blame the ecosystem; but still the conclusion does not change, and as a comparison, tablets and phones had a more successful approach at adapting or modifying the ecosystem and become usable.
You cannot use an arm chromebook as laptop because of lack of storage, applications, limited options to connect peripherals (no drivers for anything except storage). No way to print that occasional document or boarding pass (unless you have another computer or perhaps network enabled printer); no way to scan a document. The samsung had an SD slot (this one does not); but you could not show videos from your camera because of unavailable codecs (and no way to install them, despite plenty of android apps for arm that play the same formats).
Casual browsing also fails a lot because of unsupported codecs (flash, silverlight); a lot of chrome extensions do not work for arm. Apps, almost non existing.
Compared to a tablet, you get a keyboard and the ability to display multiple windows on screen; but in exchange you lose almost every other sensor or peripheral (accelerometer, gps, camera, light) which make the device useful.
Now if there were at least a sandbox to run android apps, one could (temporarily ?) address the lack of applications.
what i really miss in most (all ?) of these frameworks is an embedded markup language (markdown or variants), so that one does not have to bother with html in order to create lists, fonts, tables etc.
In my own "sttp" tool, most of the javascript is exactly for this purpose - the slide deck is just the content of a textarea and is almost readable even without formatting.
For styles, i use braces and css styles e.g.
{style1 style2 style3,some text}
which has the compactness of latex and the flexibility of css.
(I'll take this chance to give a clarification on the topic but otherwise would like to stop this thread here).
Your comment is unfair. I have contributed tons of things to the FreeBSD kernel, and to the Asterisk project, following the process that each organization uses. Some of my code (the qfq scheduler) has also been integrated in Linux by third parties who were motivated enough to carry on the work. The problem is not us being academics, but rather that there are only so many hours in a day. Some help from people more involved in "the process" would certainly be welcome.
Note that the netmap code is fairly small and self contained. It is meant to run on multiple platforms though, and I'd rather have it this ways than have to maintain two separate version. It is only thanks to this feature that i could develop VALE on FreeBSD and have it running on Linux in a matter of minutes.