HeapNet2 [Testnet 12/10/23] [Offline]

My mem is still climbing at ~6% every 12 hours, not seeing the leveling out that other folk are noticing.

1 Like
Client (read all) download progress 7873/8000
Error downloading "kali-linux-2023.3-installer-amd64.iso": Chunks error Chunk could not be retrieved from the network: d4823b(11010100)...

Yep - thats rubber ducked.

1 Like

I’m re uploading it now just to see if that changes the price of sausages

4 Likes

Seems like the 0.48 release failed to go out, hence why safeup is failing there. Rerunning that just now.

One for @roland to look into

Hmm, it should be automatic for the compiled bins. If you compiled manually, you’d need the network-contacts feature enabled. If it wasn’t happening with the compiled bins, can you share your failed node logs? :bowing_man:

There may well be more than one. So there could well be something GET related as well as what appears to have been dialback related.

I’d wager corrupt wallet here. It should be healing itself (cc @Toivo I think you asked up thread about corrupt wallets? They should be able to tell that they’re attempting to double spend and remove the already spent CNs now. If that’s not happening some logs around that fail would be handy @Josh )

7 Likes

I have had that thing happening to me and starting again with a new wallet has solved the problem.

But I think it might be also somehow related to connections. I got that hang last night again and I think I had a good wallet. Unfortunately I’m away from that keyboard until late in the evening, so I cannot double check, or provide more information. I did send my logs to @joshuef just before leaving though.

2 Likes

CLI v 0.83.48 is now out properly, and may provide a better download experience for folk.

3 Likes

On a different note, one thing I’m super happy about is getting the feel of how the idea of light nodes and heavy clients is playing out. Aside of having to forward port, the nodes are soooo hassle free compared to almost any computer program, let alone some cryptocurrency nodes. It will be such a low-barrier to running your own node, that it will feel like walking downhill.

15 Likes

@joshuef had a revelation today that might even make this considerably more so. Let’s see, some tests and even more code simplification possibly en route. The feeling we are onto something quite revolutionary here is high. Much like the simplicity of LLMs giving such credible output or, of course, the simplicity of a chaotic ant colony.

It really feels like the simplicity here is going to be amounting and will very much shake the foundations of many a decentralised approach that uses total order. I do hope it does change that world and bring us networks that massively outperform the centralised offerings.

16 Likes

This vid is in my Ubuntu home folder and I could upload it like so:
safe files upload AtUc2_6dsz0.mp4

I uploaded the file twice as shown in client/uploaded_files

8d810abd4c1c483a75e3736296076d984987d9f2b68fd3f236d12459ee55704b: AtUc2_6dsz0.mp4
8d810abd4c1c483a75e3736296076d984987d9f2b68fd3f236d12459ee55704b: AtUc2_6dsz0.mp4

I probably paid for the upload the second time also

Uploaded 116 chunks in 65 minutes 43 seconds
**************************************
*          Payment Details           *
**************************************
Made payment of 0.123610871 for 116 chunks
New wallet balance: 399.352011236
**************************************
*            Verification            *
**************************************
116 chunks to be checked and repaid if required
Verified 116 chunks in 15.052570977s
Verification complete: all chunks paid and stored
**************************************
*          Uploaded Files            *
**************************************
Uploaded AtUc2_6dsz0.mp4 to 8d810abd4c1c483a75e3736296076d984987d9f2b68fd3f236d12459ee55704b

With Google you can find the vid AtUc2_6dsz0 on Youtube. with NRS AtUc2_6dsz0 you could find it on the SAFE Network maybe, if you can link NRS to the vid…

@happybeing can’t play with VDash now, with previous testnets it took longer before the NAT warning would appear and the node would get shut down. My BIG uploads took 2 days and 1.5, unfortunately my computer shut off 90% along the way. :sweat_smile:

3 Likes

:grimacing:

First thing on my wishlist is to have uploads more tolerant to interruptions.

4 Likes

Would be fun if it picked up, where they left off
If the network chewed 44 chunks already, if interrupted it should continue to reach the 116 chunks, if you upload again, but I guess that’s easier said than done. It does retry if it fails, but what I mean

When my computer shuts down, it doesn’t start again where it went offline and it should especially if I incrementally paid for the 44 chunks already

5 Likes

it makes perfect sense we have a queue for chunks to be stored and one for stored. So we move the chunks over when stored. That way we should be able to restart where we left of no matter how many files are being uploaded in parallel.

It’s a relatively easy UX fix we can do. cc @chriso @roland

11 Likes

Hi, @Josh have you have the log of that repeatedly failed chunk upload kept ?
If so, could you please send the log to me please? thank you very much.

It might be related to a rare case that I was tracking on but failed to re-produce in our CI runs.

10 Likes

Some download attempts with the newest CLI v 0.83.48

AtUc2_6dsz0.mp4 58MB :white_check_mark:
The.Graduate.1967.REMASTERED.720p.BluRay.900MB.ShAaNiG.mkv 921MB :white_check_mark:
ubuntu-18.04.4-desktop-amd64.iso 2.1GB :white_check_mark:
ubuntu-23.04-desktop-amd64.iso 4.8GB :white_check_mark:

kali-linux-2023.3-installer-amd64.iso 4GB :no_entry:
This one is the only one giving out errors. (although it is failing on the exact same chunk as the two previous attempts on this Testnet) Something probably went wrong with that upload?

EDIT: neik is reuploading kali, will have to test it out again after that.

So overall downloads seem to be working pretty well right now :slight_smile:

10 Likes

im re uploading the kali iso right now when its done ill post and we can see if that sorted it out

6 Likes

Hey @qi_ma yes I kept it. Will get it to you shortly.

6 Likes

7 Likes

I was watching one upload closely (750 MB) and the amount of traffic is actually around 15x the file size.

  1. Every batch of chunks get uploaded x5
  2. at the same time same amount of data is downloaded (why?)
  3. Verification, every chunk gets downloaded x5

Tx/Rx are switched in the picture

Is the verification of all chunks done twice?

Is there a reason for downloading all the data to do the verification? My thought is it should be enough for the client to generate random nonce and then both client and node do hash of chunk+nonce and compare.

11 Likes

Because we didn’t implement another way yet really, it’s not been a priority as yet. There’s no wild technical reason we can’t avoid that for verification I think. Beyond :mantelpiece_clock:

14 Likes

Good. I was thinking about future UX and traffic 15x the filesize would be bad, 5x is OK i think. For the time being I agree it is not a priority, just good to know it is not the final solution.

7 Likes