HN user

injinj

75 karma

I do pubsub and caching.

  https://github.com/injinj
  https://github.com/raitechnology
Posts0
Comments57
View on HN
No posts found.

I've been running frr (free range routing) for networking, using ospf layer 3 routing between my hosts. This allows dynamic routes to be populated throughout and makes a switched layer 2 network optional, since switches tend to be expensive and obnoxiously loud and a star topology is not necessary with a layer 3 network.

I like the Supermicro Xeon D boards because I can power 6 of them off a single power supply (the GPU cables can be converted to a 4 pin cpu).

I also use systemd-nspawn (w/ dnf --installroot or debootstrap) or docker to attach instances to the network, where each has it's own layer 3 address distributed by frr.

Thanks for the refs.

If I wanted to setup z-library on freenet, an example where reputation could be greatly enhanced by users of the service yet at odds with the legal system. Could the governed outweigh the influence of the government using the reputation system? Sorry for the silly information wants to be free argument, I know you've answered such questions ad inifinitum.

The reputation system is radical departure from freenet. This feels like a google search pagerank integrated with yelp, where you initially buy keywords from freenet.org, like a domain name purchase, and then other users add or subtract from your rating.

The other thing that is different is providing a multicast mechanism to subscribers of a service.

My memory is fuzzy, but I think the original freenet was pull based, where content was replicated around the network closer to the consumers of the data. I believe there was a well known key that signed the static content, so you could retrieve data using natural language. The well known key could be updated to point to any static content, so you could emulate push by polling the well known key and getting the latest version.

The new reputation mechanism must integrate with the subscription multicast in order to limit the abuse of the network. I'd be interested in a description on how this works.

It doesn't need a raft consensus algorithm, but corrosion does converge to a consensus, doesn't it? In the OSPF example, that does needs to converge to a state that is consistent and replicated on all the routers, otherwise loops and drops will occur. I'm curious if any convergence benchmark has been done that compares raft to corrosion.

That's what I got (7950x steel legend), except that I'm running 128GB memory at 4800.

Here's my stream results (with the cpu in 105watt "eco" mode):

  $ wget https://www.cs.virginia.edu/stream/FTP/Code/stream.c
  $ gcc -O3 -fopenmp stream.c
  $ a.out

  Number of Threads counted = 32

  Copy:           45571.7
  Scale:          40672.0
  Add:            45317.3
  Triad:          42759.0
With array size 8,000,000
  Copy:           31551.3
  Scale:          30983.7
  Add:            34403.6
  Triad:          34484.1

I can never remember things. That's why my history file has 100k lines in it.

  $ do create linux bridge
  brctl addbr <bridge_name>
  ip link set <bridge_name> up

  $ do git reverse last commit
  git reset --hard HEAD~1

  $ do gcc show optimizations
  gcc -O -Q --help=optimizers

China fomo? Are these good enough to fill the needs of AI workloads of the datacenters which can no longer get the next gen NVIDIA GPUs?

I didn't see binary interpolative coding (BIC) referenced. It is one of my favorites introduced to me by the book "Managing Gigabytes" by Moffett and Bell [1]. It has great compression ratio for sequences and is commonly used in inverted indexes.

There is neat implementation [2] and technical paper [3] by Giulio Ermanno Pibiri, which I just found today by looking for it.

[1] https://people.eng.unimelb.edu.au/ammoffat/mg/

[2] https://github.com/jermp/interpolative_coding

[3] http://pages.di.unipi.it/pibiri/papers/BIC.pdf

It looks like the input word is using lodsd instruction, loading a 4 byte word, instead of a ptr increment, which could cause a 3 byte oob read if the last byte was at address 1.

I believe this is used in millions of builds, since it's been around for 20 years and Windows has a culture of winzip style software not packaged by Microsoft, but a lone programmer trying to get by with donations.

Do you have a specific exploit description? Mark Adler can remove or mark it unsafe on the github repo given a reason.

A wireshark capture shows that memcrsd is breaking up the response packets, not optimizing network, sending a lot more packets than memcached. With the 100 byte size, memcached is packing 10 PDUs per packet and memcrsd is doing 1.

Using memtier_benchmark --pipeline=1 with "memcached -t 1" and "memcrsd -r 1" shows almost identical results (141943 vs 136550) on my machine (keys 1 -> 100000). The network is where most of the CPU is spent in both memcached and memcrsd cases.

I'm slightly impressed with memcrsd/rust scaling, 32 runtimes with 16 memtier_benchark threads with pipeline=9 can produce 4 million ops/sec. They need to fix the networking parts.

I think most will use horizontal scaling anyway, and simply shard the memcached's and skip the threading concurrency. Multiple memcached's with client side sharding is hard to beat.

Decent speedup on my 3970x. Including this patch reduced the number of instructions in lzma_decoder.s (using gcc 8.3.1) by about 8% (4417 lines of asm vs 4824). With perf stat, an astonishing branches-missed reduction from 409K to 104K.

Using the firefox example from the gist:

  $ tar -cJf lib.tar.xz /usr/lib64/firefox
The xz shipped from the system:
  $ perf stat xz -c -d lib.tar.xz > /dev/null                                                                               

  Performance counter stats for 'xz -c -d lib.tar.xz':

          4,650.32 msec task-clock:u              #    1.000 CPUs utilized          
                 0      context-switches:u        #    0.000 K/sec                  
                 0      cpu-migrations:u          #    0.000 K/sec                  
               591      page-faults:u             #    0.127 K/sec                  
    19,849,912,300      cycles:u                  #    4.269 GHz                      (83.33%)
       425,290,878      stalled-cycles-frontend:u #    2.14% frontend cycles idle     (83.33%)
     1,831,640,390      stalled-cycles-backend:u  #    9.23% backend cycles idle      (83.34%)
    23,973,036,103      instructions:u            #    1.21  insn per cycle         
                                                  #    0.08  stalled cycles per insn  (83.33%)
     2,939,144,233      branches:u                #  632.031 M/sec                    (83.34%)
       409,371,860      branch-misses:u           #   13.93% of all branches          (83.33%)

       4.650679926 seconds time elapsed

       4.611657000 seconds user
       0.011931000 seconds sys
The xz patched.
  $ git clone http://git.tukaani.org/xz.git
  $ cd xz/src
  $ patch -l -p1 < ../faster_lxma_decoder_x86.patch
  $ cd .. ; autogen.sh && configure && make
  $ LD_PRELOAD=./liblzma/.libs/liblzma.so
  $ perf stat ./xz/.libs/xz -c -d ../../lib.tar.xz > /dev/null                                                              

  Performance counter stats for './xz/.libs/xz -c -d ../../lib.tar.xz':

          3,578.54 msec task-clock:u              #    1.000 CPUs utilized          
                 0      context-switches:u        #    0.000 K/sec                  
                 0      cpu-migrations:u          #    0.000 K/sec                  
               593      page-faults:u             #    0.166 K/sec                  
    15,186,685,715      cycles:u                  #    4.244 GHz                      (83.32%)
       108,663,507      stalled-cycles-frontend:u #    0.72% frontend cycles idle     (83.32%)
     8,753,057,119      stalled-cycles-backend:u  #   57.64% backend cycles idle      (83.34%)
    27,322,182,837      instructions:u            #    1.80  insn per cycle         
                                                  #    0.32  stalled cycles per insn  (83.35%)
     1,979,944,734      branches:u                #  553.282 M/sec                    (83.34%)
       104,752,154      branch-misses:u           #    5.29% of all branches          (83.34%)

       3.578973194 seconds time elapsed

       3.549329000 seconds user
       0.011942000 seconds sys

I believe libpng default zlib compression level is 6. libpng may use CRC (or adler) checksums, which account for around 30% of the decode time. In my experience with zlib, the higher compression levels have faster decode times. My reasoning at the time was (early '00s) that higher compression tends to code longer runs of copying of the dictionary. More time in the copy loop rather than the input and decode loop.

It does appear the "Node ID" section covers this issue, with the requirement that the public key back up the 40 bit key fingerprint.

What if the controller had a timer that could be set such that the network becomes static and unchanging when it expires?

people who view science through obtuse political lenses

It's not really that surprising. Prescribing Opioids like candy, outlandish prices for things like Insulin, bankrupting poor and uninsured for end of life treatments, covering up the gain of function research funded by the NIH, censoring all kinds of stuff, beginning with their President and probably a few of their friends. I'm sure some of those anti-vaxxers have friends who had COVID and came through it ok. And now, trust us, take this experimental vaccine without any backup plan in case it has adverse effects lasting a couple of weeks. Loss of work, maybe a hospital bed to pay for, etc.

The vaccine would better tolerated with a national health care plan and letting people take Ivermectin if they want it. At the moment, CVS won't fill a Ivermectin prescription, even though it quite safe, but they will fill up your pain pills no problem. I do think that the vaccine is marvelous, but I'm not naive to the failings of our medical system.

I remember downloading and compiling Mosaic and thinking that this is stupid. A glacially slow way to display text with links and graphics, who's going to want that? Why not display text as it was meant to be displayed, on a terminal.

I still think there will be a return of peer to peer eventually, since every pocket has a computer capable of computation and bandwidth unimaginable back then. The ultimate form of data privacy is when you control the power plug.

One thing I found useful is instead of

  volatile T member;

  T access( void ) { return member; }
Use volatile on the functions instead:
  T member;

  T access( void ) volatile { return member; }
This has causes all access to this-> within the function to be volatile, including read_position, write_position, overrun_flag and data[].

When inlining these functions within other parts of the code, the compiler can hoist reads into registers from the non-volatile members unless you add the compiler barrier that @ghhhhhk8899jj mentioned.