Activity for grub
-
grub created a blog post
WASTE-1.8.0 build 125 - release
-
WASTE-1.8.0 build 124 - release
-
WASTE-1.8.0 build 123 - release
-
WASTE-1.8.0 build 122 - release
-
WASTE-1.8.0 build 121 - release
-
WASTE-1.8.0 build 121 - beta
-
WASTE-1.8.0 build 120 - beta
-
WASTE-1.8.0 build 119 - release
-
WASTE-1.8.0 build 118 - release
-
WASTE-1.8.0 build 118 - release
-
File Transfers.... now operating at scale.... true tera-byte transfer scale ...
-
WASTE-1.8.0 build 117 - release
-
WASTE-1.8.0 build 117 - release
-
We've since had feedback that 'Property Fatigue' is a thing. We're not adding this option. Dev have adjusted the code so this is automatic.
-
WASTE-1.8.0 build 116 - beta
-
WASTE-1.8.0 build 116 - beta
-
WASTE-1.8.0 build 116 - beta
-
WASTE-1.8.0 build 115 - beta - we're no where near AI, but we have noticed some emergent behaviour, that we didn't explicitly design for. Under extremely higih workloads (> 16,000 files) some requests for files will timeout. They wont reach the target, telling it to send more data. The tx will auto-pause and resume. This helps auto-scale the tx and keeps the pipelines full.
-
WASTE-1.8.0 build 115 - beta - we're quietly happy with file push/pull to resume under high workloads. Releasing soon.
-
We've had to spend more time with file tx. We've also had to make use of the dormant 'initial download request' flag. That means the file on/off the wire methods have changed. For this reason, this client again operates best with clients of the same version. We've had to do this because we must be able to handle abrupt stop and start on transfers. Under full steam, we're blasted with 10's of MB of data, which has to be 'earthed' and binned if the reveiving end cancels. If an abrupt resume is issued....
-
WASTE-1.8.0 build 115 - beta
-
WASTE b114 can track over 64,000 simultaneous downloads to multiple subscribers. It can ship files over 100 GB each. It should push data at a sustained 80 to 100 MB per second.
-
WASTE-1.8.0 build 114 - release
-
WASTE-1.8.0 build 114 - release
-
WASTE Security. The per-connection privacy meter is ready for rollout in build 112. Its being put through its paces.... WASTE uses a semi-polymorphic encryption-engine. It changes co-efficients used to encrypt information. We've captured this mechanism working for file transfers. Look for the new CypherLck readout in the Extra Diagnostics Readout for transfers.... This value is the effect the poly-morphic encryption is having on the dynamic GUID, as a transfer progresses. It will jump about wildly...
-
We're shipping a newer WASTE (111) in the new beta.... expect it within 24 hours....
-
The low level file transfer plumbing is proving solid now. We continue at-scale testing, but looking at the code from a higher abstraction. We've introduced object shallow-first, then deep searching. We compare object addresses first and then value's second for all objects in lists as part of file transfer. There is more mileage in caching deep searches, for use in future shallow searches.... This is logically sensible. any search should search as fully as possible, but as fast as possible. We worried...
-
We upped the transfer total size to 260 GB. Aggregate tx speed across the 2 users... 125 MBytes+ per second.... tera-bit scale data @ giga-bit scale speeds... Coming in build 110...
-
We upped the transfer total size to 260 GB. Aggregate tx speed across the 2 users... 125 MBytes+ per second.... tera-bit scale... Coming in build 110...
-
Scalability testing continues today. We're currently pushing 130+ GB total to 2 users, involving 3 ISO's. WASTE approached a highly-compressable part of the ISO and burst to 100 MBytes+ per second. This was not sustained. 80 Mbytes+ can be reached for slightly longer. It's currently long-term sustaining 60 MBytes+ per second. We're adjusting the Transfer Feedback Loop co-efficients, which informs Dynamic Window Scaling to ensure the right bandwidth pressure is applied at all times. We think there...
-
File Transfers.... now operating at scale.... true tera-byte transfer scale ...
-
File Transfers.... now operating at scale....
-
File Transfers.... now operating at scale....
-
That's a wrap.... Today, in scalability testing, WASTE has moved 1000 GB+ in 1+ million files to 3 users. At times it had 64,000+ items queued per client, with 3 clients for 150,000+ queued transfers. At times 250+ transfers were in-flight at a sustained 60+ MBytes / 500+ Mbits per second. WASTE consumes ~1MB per transfer, so at times its in-memory footprint rose to 250+ MB. Bugs at this scale have been ironed out, mostly. You should get reliable transfers of 100's of GB of data to multiple simultaneous...
-
That's a wrap.... Today, in scalability testing, WASTE has moved 1000 GB+ in 1+ million files to 3 users. At times it had 64,000+ items queued per client, with 3 clients for 150,000+ queued transfers. At times 250+ transfers were in-flight. WASTE consumes ~1MB per transfer, so at times its in-memory footprint rose to 200+ MB. Bugs at this scale have been ironed out, mostly. You should get reliable transfers of 100's of GB of data to multiple simultaneous users. You should get very good queue handling...
-
109 is just completing a scalability test. Its transferring 100gb in 150,000+ files to 3 users at the same time. Thats 300 GB in total, in 450,000 files in total across 3 seperate users. Once we're stable at this scale, we'll release the code and run-time.
-
109 is just completing a scalability test. Its transferring 100gb in 150,000+ files to 2 users at the same time. Once we're stable at this scale, we'll release the code and run-time.
-
WASTE-1.8.0 build 109 - release - at scale transfers - 100 GB+ sent to 3 users in parallel.
-
WASTE-1.8.0 build 109 - release - at scale transfers - 100 GB+ sent to 3 users in parallel.
-
WASTE-1.8.0 build 108 - release
-
WASTE-1.8.0 build 107 - release
-
WASTE-1.8.0 build 107 - release
-
WASTE-1.8.0 build 106 - release
-
WASTE-1.8.0 build 105 - release
-
WASTE-1.8.0 build 104 - release
-
WASTE-1.8.0 build 103 - release
-
WASTE-1.8.0 build 102 - release
-
WASTE-1.8.0 build 101 - release
-
WASTE-1.8.0 build 100 - release
-
WASTE-1.8.0 build 100 - beta
-
WASTE-1.8.0 build 100 - beta
-
WASTE-1.8.0 build 99
-
WASTE-1.8.0 build 99
-
WASTE-1.8.0 build 99
-
WASTE-1.8.0 build 99
-
WASTE-1.8.0 build 98
-
WASTE-1.8.0 build 97
-
WASTE-1.8.0 build 96
-
WASTE-1.8.0 build 96
-
WASTE-1.8.0 build 96
-
WASTE-1.8.0 build 95
-
WASTE-1.8.0 build 95
-
WASTE-1.8.0 build 94
-
WASTE-1.8.0 build 93
-
WASTE-1.8.0 build 92
-
WASTE-1.8.0 build 92
-
WASTE-1.8.0 build 091
-
WASTE-1.8.0 build 090
-
WASTE-1.8.0 build 089
-
WASTE-1.8.0 build 088
-
WASTE-1.8.0 build 087
-
WASTE-1.8.0 build 086
-
WASTE-1.8.0 build 085
-
WASTE-1.8.0 build 084
-
WASTE-1.8.0 build 083
-
WASTE-1.8.0 build 082
-
WASTE-1.8.0 build 081
-
LZMA Compression / Decompression - Nice example from our code. C friendly with Vector output no less :)
-
WASTE-1.8.0 build 080
-
WASTE-1.8.0 build 079
-
WASTE-1.8.0 build 075
-
wxWasteagain-2019.03.01.1-1.8-build-70-share
-
LZMA Compression / Decompression - Nice example from our code. C friendly with Vector output no less :)
-
WASTE and LZMA Compression on the wire...
-
Public-Key File-Transfer Authorization - update1
-
WASTE Security – how it protects your comms - Privacy Meter Concept
-
Public-Key File-Transfer Authorization
-
Performance. WASTE breaks 320+ MBits per second @ Build 67
-
LZMA Compression / Decompression - Nice example from our code. C friendly with Vector output no less :)
-
LZMA Compression / Decompression - Nice example from our code. C friendly with Vector output no less :)
-
LZMA Compression / Decompression - Nice example from our code. C friendly with Vector output no less :)
-
LZMA causes people head-aches, sleepless nights and can lead to a slow and painful brain degradation. Here is our LZMA code for those who struggle with it. Bear in mind that LZMA ALWAYS ships its header. If it doesn't compress your data, it will leave it at the size it is + LZMA_PROPS_SIZE, the LZMA properties 5 byte header holder. Its for this reason its very hard to include in WASTE. WASTE has to use fixed length data to enable its very clever security scheme to operate with ruthless efficiency....
-
LZMA causes people head-aches, sleepless nights and can lead to a slow and painful brain degradation. Here is our LZMA code for those who struggle with it. Bear in mind that LZMA ALWAYS ships its header. If it doesn't compress your data, it will leave it at the size it is + LZMA_PROPS_SIZE, the LZMA properties 5 byte header holder. Its for this reason its very hard to include in WASTE. WASTE has to use fixed length data to enable its very clever security scheme to operate with ruthless efficiency....
-
LZMA causes people head-aches, sleepless nights and can lead to a slow and painful brain degradation. Here is our LZMA code for those who struggle with it. Bear in mind that LZMA ALWAYS ships its header. If it doesn't compress your data, it will leave it at the size it is + LZMA_PROPS_SIZE, the LZMA properties 5 byte header holder. Its for this reason its very hard to include in WASTE. WASTE has to use fixed length data to enable its very clever security scheme to operate with ruthless efficiency....
-
WASTE and LZMA Compression on the wire...
-
wxWasteagain-2019.02.09.1-1.8-x-build-65.0.0.0
-
wxWasteagain-2019.02.09.1-1.8-x-build-65.0.0.0
-
wxWasteagain-2019.02.09.1-1.8-x-build-65.0.0.0
-
wxWasteagain-2019.02.09.1-1.8-x-build-65.0.0.0
-
WASTE and LZMA Compression on the wire...
1 >
