lrizzo

same as in real life?

I think there are two different use cases:

- 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

Almost 10 years ago I wrote sttp

http://info.iet.unipi.it/~luigi/sttp/

plain javascript + markdown variation, allows receivers to sync with the presenter using AJAX (that was the name, at the time ?) long polls.

20 years ago I extended Magicpoint to send (and receive) content and commands over RTP

30 years ago... I still used a overhead projector.

I realize it's been 10 year since I last worked on the subject, and this days I use a mix of high tech and low tech solutions

http://info.iet.unipi.it/~luigi/document-camera/

> "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 ...

http://info.iet.unipi.it/~luigi/wb/

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 believe it is either "force portrait" or "autorotate", there is no "force landscape".

I have two links related to tiled window management:

The links are for WM configurations that let you move or resize windows keeping the corners on a configurable grid:

[1] https://github.com/luigirizzo/lrtile-chrome (chrome extension) Ctrl+Shift+Arrow move the current window, Ctrl+Search+Arrows resize it

     This works for all Chrome windows so it platform independent. 

(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.

To be precise zfec uses Vandermonde codes and it is derived from my old fec library from 1996-97. See http://info.iet.unipi.it/~luigi/research.html#fec (in 90's web style).

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 ?

and the mismatch between the number in the pdf and the one in the manpage/mail is due to subsequent optimizations.

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 onload="clock()"> 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.

Among other things, the difference is speed: VALE can do 18 Mpps versus the 0.8 Mpps of a Linux bridge. And sometimes you do need speed, maybe not for virtual machines but e.g. if you want to stress test your network monitors, routers, IDS etc. For instance, using VALE we found out a missing event notification in QEMU/KVM which limited the receive speed to 50 Kpps, and a one-line fix brought it up to 1 Mpps.

A very thorough examination: filed 2006 granted 2012. But i understand why it took so long, they also had to invent multi-base fractional numbers (days hours and minutes: "timestamp to-the-minute" is repeated eight times in the claim) to support the invention. Who had heard that before.

Coming next: a patent that supports notifications accurate "to the second".

excellent tool. For content creation it could be coupled with some markdown tool written in javascript. I have been using this approach for a while, I put the content in a textarea and the browser does the conversion for you. The formatting instructions (to apply css styles) are similar to LaTeX which i am familiar with and is not too visually intrusive.

You can see an example at http://info.iet.unipi.it/~luigi/netmap/slides.html

These days, doing proper packet scheduling nowadays is probably a better alternative to AQM than approximated solutions such as RED and many many variants that appeared in academic papers.

RED was designed at a time when implementing packet schedulers was expensive (theory was not completely there yet, firewalls were not widespread, etc.). Now there are fast packet scheduler implementations available. Our own QFQ [1] is distributed with the official FreeBSD and Linux sources, and runs reasonably fast even on an OpenWRT device (remember that AQM needs to act at the bottleneck [2], which is mostly your DSL router for upstream traffic).

You could really try it out easily, and if you are willing to set up a few dummynet pipes [3] (FreeBSD/Linux/Windows) you don't even need to act on the DSL router.

References:

[1] http://info.iet.unipi.it/~luigi/qfq/ but the code is already part of recent FreeBSD and Linux distributions (edited: and even on OSX you'll find an older but similar scheduler as part of ipfw+dummynet), you just need to load the relevant modules.

[2] there were, long ago, some proposals/products which did ack pacing on the reverse path to do cong.control on the forward path. I think it is tricky to make them work.

[3] http://info.iet.unipi.it/~luigi/dummynet/ . You can set two pipes with a bandwdith slightly below that of the DSL link, so you can control the bottlenecks. How can you know what is the bottleneck bandwidth is a different story. You could look at the negotiated speed on the modem, often available through the web pages, but probably you'll have other bandwidth caps elsewhere. You could try to run some of the BW probing apps to some nearby host, hoping that the bottleneck is your local DSL, and dynamically reconfigure the pipes accordingly. I have not tried this yet.

cool project. are you aware (or have considered) of similar projects for the RDP (rdesktop) protocol ?

i believe this tool (and the one in Lion/XCode) uses ipfw+dummynet, which is available also for linux/openwrt and windows at http://info.iet.unipi.it/~luigi/dummynet/ (you can find also some documentation material there).

It is a dependency hell, ready to fire at the moment one of the packages changes its interface (API, behaviour, file layout, ...) recursively breaking a fraction of its dependents. Then you end up with multiple versions of the same package, versioned libraries, private copies of libraries and tools, and so on.

Reuse works great on a small scale, but otherwise requires a lot of discipline both from the provider (who must refrain from interface changes, or have support for multiple versions from day one), and the consumer (who should be very considerate on which packages and features he uses).

this is yet another web-based presentation tool. Compared to other similar tools, the two major advantages are: i) a simplified syntax for slides, similar to reStructuredText http://en.wikipedia.org/wiki/ReStructuredText, and ii) a simple server-side backend so that multiple "listener" can have their slides move in sync with those of the speaker. Resizing using the browser's controls (ctrl +/-) generally works well to adapt to different screen resolutions, and i am trying to add support for tablets and phones and similar devices. There is also a simple "edit" mode in which you can modify, still within the browser, the textarea that contains the presentation, and rudimentary support for plotting, and some simple transition effects.

sttp shares the disadvantages of this family of solutions: if you have images or other embedded content the presentation is not a standalone file; export-to-pdf is weak; no math; etc. - but it can do the job for small presentations, and especially it really enforces you to have a consistent slide style across the presentation

The "old" pf_ring is only meant for packet capture and involves packet copies, so it is several times slower than netmap. There is a newer "Direct Network Access" (DNA) version of pf_ring which avoids copies and has the same performance of netmap, but is much more fragile because in DNA the userspace program writes directly into the NIC registers and rings (so it can crash the entire OS), whereas in netmap the NIC programming is filtered by system calls.

please look at the paper linked to the url, which defines the problem and the metrics in more detail.