01:56:00 <bigslim[m]> 8 hours in and I’m at 63% sync with 800,000 blocks left. No clue how someone can full sync monero in 5 hours
02:06:10 <sethsimmons> With all the talk of syncing i figured I’d test it — 2h20m in and 61% done, 850000 to go.
02:06:36 <sethsimmons> 3700X/16GB/1TB NVMe
02:10:20 <sethsimmons> Lots of other normal background processes etc.
02:10:51 <sethsimmons> No abnormal or high disk, CPU, or network usage that I can tell, no idea what the bottleneck is that prevents a faster sync.
02:11:38 <sethsimmons> Everything looks way underutilized, and this is a very fast NVMe drive so that shouldn’t be that much of a bottleneck (Samsung 970 EVO)
02:13:14 <sethsimmons> Upping out_peers seems to have increased sync speed quite a bit instantly from 8 to 50
02:18:09 <sethsimmons> Going to restart with 50 out_peers.
03:13:57 <bigslim[m]> Holy shit you have 50 out peers
03:14:43 <bigslim[m]> I suppose I’ve never attempted increasing out peers since I never limit that. I thought by default it is not limited like in person
03:14:48 <bigslim[m]> Peers*
03:19:08 <nioc> default is 8
03:53:29 <bigslim[m]> Well then. Set to 20 and will check in the am
05:25:22 <riceandbeans> Can't go anywhere because of coronavirus but leave it to a cryptocurrency to make you say from home, fucking gas prices.
05:53:35 <Inge-> sethsimmons: interested in your results.
06:32:16 <algo_max[m]> First time experience - I synced the whole blockchain a few days ago and it took me like a week (before I had a pruned one, it was somewhat faster, but similar). :/ Will check top next time to see what's taking up the time.
07:48:24 <kayront> FYI, someone just pointed out in another chat that the Tasks app now supports XMR donations: https://tasks.org/docs/donate.html
07:49:20 <kayront> I use it a lot myself, otherwise not associated with them in any way. if you don't know the app [and care about being a nice productive bunny], do check it out!
08:33:54 <Inge-> kayront: running nextcloud or ownclod as well?
08:44:22 <kayront> Inge-: been on the todo list for like half a year
08:44:25 <kayront> i'll get to it :p
09:07:28 <Inge-> sounds way to familiar
09:44:15 <a20eac1d> Hey folks. I don't know if this is the right place to ask for help. I may have lost a lot of money because I cannot find my Monero wallet anymore. Would anybody be able/willing to help me? Thank you! :)
09:44:53 <Inge-> can you be slightly more descriptce about what heppend?
09:45:12 <Inge-> where was the wallet the last time you saw it?
09:49:01 <a20eac1d> All of this happened a few months ago and I'm just now trying to pick up the pieces. I have two main issues - Problem #1: I held my Monero on a paper wallet for too long and then bought a TREZOR for cold storage. I transferred the Monero from the paper wallet to another address, that by now is marked as "Unknown recipient" in the Monero GUI
09:49:01 <a20eac1d> "0.17.0.1-release". I can see in the transaction log that the entire wallets funds were transfered, I have the Date, TXID, Amount and Rings. Is there any way I can find out what address this was sent to? Problem #2: When I create a Monero wallet that is managed by my TREZOR it does not match any existing Monero wallet on my hard drive. Even when I
09:49:02 <a20eac1d> try out all passwords I have on the TREZOR, the wallet that is being created is empty and new. Is this an issue with the Monero hard fork? How do I find the matching wallet now, maybe there is a software like BTCRecover that works for Monero?
09:52:00 <selsta> a20eac1d: does the address match? are you setting a Trezor passphrase?
09:53:39 <a20eac1d> I have tried all TREZOR passphrases I have used and the addresses do NOT match. There was a recent update to both TREZOR and Monero for the hard fork I believe, maybe this caused some changes in the address deriving algorithm and now the same seed does not produce the same address?
09:54:15 <selsta> the derivation algorithm did not change, you have to enter the same passphrase as you used initially
09:54:20 <selsta> or none if you didn’t use one back then
09:54:33 <selsta> different passphrase -> different address
09:55:22 <selsta> did you write down your initial Trezor address? or how do you know it?
09:56:40 <a20eac1d> I have a document that has the first word of my TREZOR seed (this matches) and the first few addresses of the Monero account, but none of the passwords I use produce the correct address
09:57:48 <selsta> just to confirm, did you also try without a passphrase?
09:58:19 <a20eac1d> Yes, empty passphrase did not work either
10:02:04 <selsta> a20eac1d: if you want to make sure you can install the old monero version (and optionally also the old trezor firmware) but I’m 100% sure that the derivation did not change
10:02:44 <selsta> only advice is try a bit more regarding passphrase :/
10:07:03 <a20eac1d> Got it, thanks. So there is no utility like BTCRecover for Monero?
10:07:19 <selsta> I’m not familiar with BTCRecover.
10:08:31 <a20eac1d> If you lost part of your seed or password it will help you recover them by trying out all combinations
10:09:05 <a20eac1d> I have my seed and I have a list of possible passwords, maybe a tool can help me check all Monero accounts associated with them for a balance?
10:10:13 <selsta> the problem is with monero being private you have to scan the blockchain to check for your balance
10:10:26 <selsta> so it would take 10 minutes per seed + password combination
10:10:37 <a20eac1d> Still better than doing it manually^^
10:10:50 <a20eac1d> I have a limited number of combinations, but checking each one manually will take forever
10:11:28 <selsta> if you have a local daemon synced + specify a wallet creation date it should take less than 10 minutes
10:11:46 <selsta> but yea, still tiresome
10:12:07 <a20eac1d> But the Monero account is managed by a TREZOR, so I need to restore my TREZOR with a seed, enter the password using the display and check the Monero balance. Thats tiresome
10:12:35 <selsta> right, I thought you know your trezor seed
10:13:21 <a20eac1d> I do, atleast I'm 99.9% sure. The first word I have written down matches one seed that I know. But just in case I would have to try a few old seeds too.
10:13:41 <Inge-> I wonder if trezor and ledger use the same derivation path from bip39 -> monero mnemonic
10:15:01 <Inge-> a20eac1d: I doubt anything has changed with regards to what address Trezor makes based off the trezor seed words.
10:15:46 <Inge-> If you can access the old wallet file, it might contain the address you sent to. but this is stored as metadata, and not something that can be figured out later when restoring wallet from seed words.'
10:18:10 <a20eac1d> I do have the wallet file and also all transaction details and public/private view/spend keys to the old paper wallet where the Monero was before. Can I somehow decrypt/restore the recipient address with this?
10:20:39 <a20eac1d> When I enter the transaction id and private view key into xmrchain.net to decode the outputs I can see two output public keys. Does this somehow tell me where the money went to?
10:21:33 <selsta> a20eac1d: https://xmr.llcoins.net/checktx.html
10:21:36 <selsta> does this help?
10:25:49 <a20eac1d> The site doesnt seem to work. Failed to get transaction data! Perhaps MoneroBlocks is down?
10:27:46 <sethsimmons> Inge-: algo_max Results from my test sync with 50 out_peers: 3h57m
10:27:46 <sethsimmons> Running with default 8 out_peers now to compare. Any other settings I should play with to compare sync times? selsta or moneromooo? Trying to see if I can track down the bottleneck (at least for me) and out_peers seems promising so far.
10:29:04 <selsta> sethsimmons: 4 hours to completely sync up? nice
10:29:19 <sethsimmons> Yup 🙂
10:29:49 <sethsimmons> Very smooth, testing with the default 8 peers but it was much faster the moment I set out_peers to 50 on my initial test.
10:30:18 <sethsimmons> Seems to be my threshold at least, but would love any other recomended flags or settings to test out and I'll compile the results.
10:30:21 <selsta> a20eac1d: Possible.
10:30:49 <a20eac1d> selsta Actually, I think the site you linked wont work anymore. I get 301 Moved Permanently from the requests
10:30:58 <a20eac1d> I think moneroblocks changed their api and they didnt update
10:31:05 <a20eac1d> Any other sites like this?
10:31:23 <selsta> luigi1111: ^
10:33:12 <selsta> https://monero.stackexchange.com/questions/6134/how-do-i-as-a-sender-verify-that-my-transaction-actually-arrived
10:33:15 <selsta> does this help?
10:40:31 <a20eac1d> selsta Not really, the instructions seem to be outdated, commands dont exist and the menu options have also changed
10:43:02 <dEBRUYNE> Those guides basically only work if you still have the initial wallet cache
10:43:44 <beruang[m]> Hello i have a Q
10:43:58 <dEBRUYNE> Ask away
10:44:03 <beruang[m]> Ok
10:44:16 <a20eac1d> Does the wallet cache expire? If not, I should have it still on my disk
10:44:22 <beruang[m]> Can whe talk dutch?
10:44:33 <selsta> It does not expire.
10:45:05 <Inge-> sethsimmons: still no indications of a bottleneck anywhere, then?
10:45:28 <dEBRUYNE> a20eac1d: It should be on the system where you initially performed the transaction
10:46:07 <sethsimmons> <Inge- "sethsimmons: still no indication"> I didn’t get to monitor the whole time, but saw much increased network and CPU usage when increasing peers (but still *well* below the systems ability).
10:46:39 <Inge-> sethsimmons: I'm not surprised that CPU isn't maxed out - but perhaps n threads did max out?
10:46:49 <sethsimmons> Still seems like I could get a faster sync by increasing peers even higher, as I can’t imagine the SSD is overwhelmed by the ~5-10mb/s write, even if it is random rw heavy.
10:47:02 <sethsimmons> <Inge- "sethsimmons: I'm not surprised t"> I saw 1-2 cores being near 100%, that’s it.
10:47:21 <beruang[m]> So i have a new pc. How to install the monero app on the new pc. Can't find it on the internet or youtube. is there somewhere a tutorial?
10:47:33 <dEBRUYNE> Which operating system?
10:47:48 <sethsimmons> Windows 10
10:47:50 <beruang[m]> windows
10:47:52 * sethsimmons ducks
10:47:53 <beruang[m]> yep
10:48:02 <Inge-> sethsimmons: right. so on limited data my guess is still that we are limited by the paralellizability of processing the downloaded data.
10:48:25 <Inge-> beruang[m]: did you check out the download section of getmonero.org ?
10:48:38 <sethsimmons> <Inge- "sethsimmons: right. so on limite"> Definitely seems like it, although if that was 100% the case increasing peers wouldn’t help, right?
10:48:57 <Inge-> sethsimmons: yeah go again with like 100 peers and see if there is a diff
10:49:06 <Inge-> I'll see if I can give it another spin here as well
10:49:07 <dEBRUYNE> beruang[m]: Do you have an SSD on that system?
10:49:20 <Inge-> a20eac1d: only if you have the *actual* wallet where you did the transfer, will you be able to see the destination address.
10:49:35 <sethsimmons> Inge-: trying with default first to make sure the eye test was legitimate, then I’ll compare with higher and higher peer counts
10:49:42 <Inge-> k
10:49:57 <Inge-> I did end up <5 hours with just default peers on my earlier tests
10:50:10 <beruang[m]> yes but there is nothing about settingup a monero on a new pc, my ols one has the data
10:51:12 <dEBRUYNE> So you basically want to transfer your wallet etc. from the old system to the new system?
10:51:15 <beruang[m]> yes have ssd
10:52:02 <beruang[m]> yep
10:52:13 <MyWay> hello
10:52:31 <dEBRUYNE> On the old system, did you run a local node?
10:52:34 <beruang[m]> and install monero wright on my new pc
10:52:49 <beruang[m]> no the gui
10:54:47 <dEBRUYNE> Yes, but what wallet mode did you run?
10:55:13 <beruang[m]> i looked at the youtube video from Rex Kneisley
10:55:38 <beruang[m]> o sorry....local node
10:58:06 <dEBRUYNE> np
10:58:20 <dEBRUYNE> Do you remember on the old system if you downloaded the .exe or the .zip file from the getmonero website?
10:59:39 <beruang[m]> i used both........at this time i have updatet monero on my old pc and it is running well
11:00:22 <beruang[m]> but the old one is gooing with pension
11:02:41 <beruang[m]> so now i have to install monero on my new pc but there is no option to get back my old wallet, otherwise than use my prases?
11:05:15 <selsta> You can copy your old wallet on an USB stick.
11:06:24 <beruang[m]> That is what i try to do. This will have no harm?? Are there hidden files?
11:07:07 <selsta> you have to copy the file called "wallet_name" and "wallet_name.keys"
11:07:54 <copenhagen_bram[> Hello! When I run Monero GUI, I keep getting these "Maximum number of clients reached" errors. Every keystroke spams the error log with "Maximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reachedMaximum number of clients reached" and xscreensaver doesn't work because of a similar error
11:08:44 <selsta> copenhagen_bram[: where do you see this message?
11:08:59 <copenhagen_bram[> <selsta "copenhagen_bram: where do you se"> In the terminal where I started `monero-wallet-gui`
11:09:13 <selsta> This does not look like a monero message.
11:09:29 <beruang[m]> Ok! After that i will place them on my new pc and start the setup of monero on my new pc. Is a solusion i think! Thanks. Are there onther ways to run the monero on a new pc?
11:10:31 <copenhagen_bram[> <selsta "This does not look like a monero"> I just tried to run `xscreensaver-demo` and it says "Maximum number of clients reachedxscreensaver-demo: 06:09:16: Gtk-warning: cannot open display: :0.0
11:10:43 <copenhagen_bram[> > <@freenode_selsta:matrix.org> This does not look like a monero message.
11:10:43 <copenhagen_bram[>  * I just tried to run `xscreensaver-demo` and it says "Maximum number of clients reachedxscreensaver-demo: 06:09:16: Gtk-warning: cannot open display: :0.0"
11:14:18 <dEBRUYNE> beruang[m]: Easiest is just to open the GUI on your new PC and go through the setup process
11:14:26 <dEBRUYNE> To load your wallet, you can use the 'Open a wallet from file' option
11:14:34 <dEBRUYNE> and then select the .keys file that you transferred with the USB
11:16:06 <copenhagen_bram[> So yes, it does not look like a Monero message. But I am almost certain the message is being caused by the Monero GUI, somehow.
11:17:33 <selsta> It’s from xorg apparently according to Google.
11:17:57 <copenhagen_bram[> Okay. So why is Monero GUI affecting Xorg like this?
11:17:57 <selsta> Did you use the version from getmonero.org or from your package manager?
11:18:14 <selsta> I have never seen anyone report this issue so I don’t know.
11:18:27 <copenhagen_bram[> Package manager, I'm on Debian and I used the Whonix issue recommended from getmonero.org
11:18:38 <copenhagen_bram[> the Whonix repository*
11:18:56 <selsta> please try to use the getmonero.org binary to check if the issue persists
11:19:07 <copenhagen_bram[> This one: https://gitlab.com/whonix/monero-gui#how-to-install-monero-using-apt-get
11:21:58 <moneromooo> sethsimmons: interesting settings include: --max-concurrency --block-sync-size --prep-blocks-threads --fast-block-sync (enabled by default) --block-download-max-size --sync-pruned-blocks (if you prune your db only) --limit-rate-down
11:30:38 <bigslim[m]> moneromooo: 16h 48min and only 13k blocks remaining on sync
11:31:14 <bigslim[m]> Quite a bit better than 14.0 sync by 5 days
11:31:23 <sethsimmons> bigslim: What hardware are you syncing on?
11:31:52 <sethsimmons> I just finished a sync in under 4h...
11:31:55 <bigslim[m]> 1950x, m.2 Sabrent rocket ssd
11:32:23 <bigslim[m]> I have not had a single in connection though. Only 8 outs.
11:32:31 <selsta> Does not matter
11:32:43 <sethsimmons> Wel if you don’t allow ins/port forward you won’t, but in_peers won’t help a sync
11:32:55 <sethsimmons> Somethings off in your setup, that’s waaaaaay too long for that HW
11:33:15 <sethsimmons> I can sync similar HW but with an Intel 660p NVMe drive in 6h
11:33:21 <sethsimmons> 1950X as well
11:33:43 <bigslim[m]> Monerod has not used more than 8GB ram and maybe 20% cpu
11:33:58 <sethsimmons> How is your network? Is your SSD healthy and not overfill?
11:34:04 <sethsimmons> *over full
11:34:18 <bigslim[m]> It’s a 1tb with 50% capacity
11:34:47 <sethsimmons> M.2 or NVMe? And what model? Curious the stats.
11:34:51 <bigslim[m]> No other applications running either. Just monerod
11:34:56 <bigslim[m]> Nvme
11:35:08 <sethsimmons> My <4h sync was with tons of background processes etc.
11:35:09 <selsta> I think I wrote this before but even the $10 Hetzner VPS synced in 6 hours, which has way worse hardware
11:35:11 <bigslim[m]> It’s the pcie3.0 version
11:35:20 <sethsimmons> And that was just a 3700X and NVMe SSD.
11:35:32 <sethsimmons> <selsta "I think I wrote this before but "> Yeah something is off here
11:35:48 <sethsimmons> Is your network good for other tasks? What’s your speed? Do you notice a lot of dropped packets etc?
11:35:49 <bigslim[m]> It’s not fast sync through. No pruning
11:35:55 <moneromooo> Yeah, computer needs to be in the "on" setting.
11:35:56 <bigslim[m]> Though*
11:35:57 * moneromooo runs
11:36:00 <sethsimmons> Yeah no pruning on either of mine.
11:36:06 <sethsimmons> What do you mean by fast sync?
11:36:09 <bigslim[m]> Hmm
11:36:14 <moneromooo> Ooooh...
11:36:18 <asy> sethsimmons: m.2 can be nvme or sata (well, ahci). you can tell which it is by looking at the keys/missing bits on the connector :)
11:36:18 <selsta> bigslim[m]: did you set --fast-block-sync=0 ?
11:36:27 <moneromooo> Yeah, no fast sync wlil definitely slow things down, lots of extra PoW checks.
11:36:52 <bigslim[m]> Like increasing max concurrency, fast-block-sync, or block sync size
11:36:58 <sethsimmons> <asy "sethsimmons: m.2 can be nvme or "> It’s normally SATA IIRC, but thanks for the tips 🙂
11:37:09 <sethsimmons> <selsta "bigslim: did you set --fast-bloc"> So you did not do this, bigslim?
11:37:23 <selsta> Because this would disable fast sync, it is activated by default.
11:37:43 <bigslim[m]> No just ran straight monerod with restricted rpc
11:37:49 <sethsimmons> Ok
11:38:09 <sethsimmons> Something is definitely off on your setup, no way it should take that long with your HW. What FS/OS are you running?
11:38:21 <bigslim[m]> Windows :)
11:38:22 <Quotes> fuck windows, use linux!
11:38:23 <sethsimmons> <sethsimmons "Is your network good for other t"> And what about this?
11:38:34 <sethsimmons> <bigslim[m] "Windows :)"> Also windows here.
11:38:52 <bigslim[m]> 200mbps fiber to the box
11:38:59 <copenhagen_bram[> <selsta "please try to use the getmonero."> I'm extracting monero-gui-linux-x64-v0.17.0.1.tar.bz2 and waiting for the currently running Monero to finish shutting down
11:39:27 <sethsimmons> bigslim: I’m on 1gbps, but I’m not seeing anything more than 5-10MB/s used, so I don’t think bandwidth is the limiter.
11:39:28 <selsta> ok sounds good
11:39:44 <sethsimmons> Is the quality of your connection good? No other noticed issues with the network, no large packet drops, etc?
11:40:24 <bigslim[m]> I was seeing up to 32mbps used in task a manager around 64% sync but now it’s 7mbps here and there with 13k blocks left
11:40:57 <bigslim[m]> I have 0 network issues. Actually quite happy with it over the old cable
11:40:58 <moneromooo> At the end of the sync, it tells you stats on the sync. Add: set_log +sync_info:INFO
11:41:49 <bigslim[m]> Ok I’ll run it when it’s done.
11:41:58 <moneromooo> No, run it before it's done :)
11:45:03 <sethsimmons> bigslim: There’s no chance you have a second HDD that is a spinner that could somehow be the storage for the blockchain, do you?
11:45:28 <copenhagen_bram[> Wow, Monero is still closing. Should I hit ctrl-c in the terminal??
11:45:34 <sethsimmons> I have no idea how a sync could take that long on a good NVMe SSD, or even a crappy SATA SSD for that matter.
11:45:42 <selsta> copenhagen_bram[: should be fine
11:47:02 <sethsimmons> bigslim: I’ll test a fresh sync on 17.0.1 right now on my 1950X/32GB/1TB Intel 660p NVMe SSD to compare.
11:53:35 <sethsimmons> To note: test machine has several other nodes running including Monero nodes for stage/testnet, among many other things.
11:54:52 <sethsimmons> And its syncing at the same time as my other test node on the same network :P
12:13:47 <thomasb06> Hello. What is the channel for the website?
12:14:35 <Vanessa53Wuckert> thomasb06: #monero-site
12:14:46 <thomasb06> Vanessa53Wuckert cheers
12:42:19 <bigslim[m]> sethsimmons: no hdd. I data dir to my nvme. It’s not the boot drive
12:42:44 <bigslim[m]> But still shouldnt matter
12:43:14 <bigslim[m]> 18hrs is not horrible for 90gb worth of blockchain sync
12:48:50 <sethsimmons> It's pretty horrible compared to everyone elses numbers, which is why I'm so curious why its so far off of what your HW is capable of.
12:49:15 <sethsimmons> had to restart my sync because I accidentally had out_peers set to 50, but was already to 62% in <1h
12:49:23 <sethsimmons> Will report back once it finishes
12:50:35 <selsta> bigslim[m]: but is it a network drive?
12:52:43 <bigslim[m]> Nope it’s on a mobo slot
12:53:22 <bigslim[m]> Top of the line everything for 1950x setup
12:54:32 <bigslim[m]> Imo it’s windows fault
12:54:38 <bigslim[m]> I like to blame windows for all performance issues lol
12:55:08 <marmulak> it often is
13:00:03 <sethsimmons> My 3700X is windows but my 1950X is Ubuntu. So will be an interesting comparison ther
13:00:03 <Quotes> fuck windows, use linux!
13:05:32 <marmulak> :o
13:09:08 <jason_> if an affluential residential flag was deactivated due to no commercial, and the only commercial lot connected was previously de-activated due to no craft and both were de-activated at the same tick, will they only become active one at a time or would both be expected to become active at the same time, provided a craft flag was connected?
13:10:42 <jason_> wrong room -_-
14:05:21 <luigi1111> hm
15:46:05 <Inge-> What are the expected min/max/median time for d++ transactions to be propagated?
15:47:02 <vtnerd> the max is little hard to specify since the embargo timer is randomized eponentially - should <5 mins
15:47:27 <vtnerd> the median depends on the latency between nodes on the path, and how many blackholes (or other potential bugs) get hit on the path
15:47:49 <moneromooo> Does it send to one or two peers ?
15:47:57 <vtnerd> one peer, as per protocol
15:48:13 <Inge-> It really changes the dynamic where you before would see it pop up almost immediately on send
15:48:57 <vtnerd> the tor mode with white noise sends to two, because i2p/tor should be hiding the ip and one does have no redudancy, and also helped with possibly mitigating the white noise path (need to write my intent on that somewhere in a markdown)
15:48:57 <selsta> Inge-: that's because there is this bug currently where it syncs it to desynced peers
15:49:06 <selsta> sends*
15:49:11 <Inge-> fair selsta
15:49:13 <Inge-> Assuming a lack of blackholes and bugs, can you say something qualified about expected median?
15:49:17 <selsta> it should get better once most are upgraded to v0.17.1.0
15:49:18 <moneromooo> Ah, so that's where I must have picked this nagging feeling I saw two somewhere :)
15:50:15 <vtnerd> yeah, and perhaps that needs to be tweaked, but sending out over i2p/tor is slightly different than the context in the d++ paper
15:50:40 <vtnerd> the code is shared, so its easy to mix-up unfortunately
15:51:17 <selsta> Inge-: afaik if everything works well it should not be much longer than previously
15:51:24 <vtnerd> for median - ~3s ? I'm not sure we'd need to real-world testing. I couldn't simulate the entire network by myself easily
15:52:07 <selsta> vtnerd: do you have a good fix for transactions getting marked as failed with restricted rpc nodes?
15:52:14 <vtnerd> we can bring it down by optimizing the p2p path (the deserialization/serialization in particular) - something I hope to get round-toit
15:52:55 <vtnerd> the only solution I have to update the wallet side to recognize that sending over restricted rpc is now special
15:53:22 <vtnerd> if the txes are being "lost" less, than that error should be seen less frequently, but still needs a fix
15:53:44 <vtnerd> the only other fix is to have the rpc on daemon side tracking TCP connections and which tx sent it
15:54:03 <vtnerd> which fails if the wallet rolls to another TCP connection (probably rare, but possible)
15:56:19 <Inge-> vtnerd: I'm kind of disappointed that you can't simulate the monero network.
15:56:26 <moneromooo> Maybe storing a set of RPC-received txids in the connection context.
15:56:46 <moneromooo> That sounds pretty simple, and the context is passed (or can be passed) to the RPC handler.
15:56:51 <Inge-> but yeah, if there is a 3 second median - with a rare one going up towards 5 minutes .. that sounds pretty ok
15:58:47 <bigslim[m]> moneromooo: blockchain synced. Should I run set_log + sync_info:INFO
15:59:03 <moneromooo> No. Too late now.
15:59:06 <bigslim[m]> Or set_log sync_info:INFO
15:59:14 <bigslim[m]> Oh
15:59:15 <moneromooo> It was: set_log +sync_info:INFO
15:59:23 <bigslim[m]> Well then
15:59:28 <bigslim[m]> Sad day
15:59:36 <bigslim[m]> So run that before starting sync?
15:59:49 <moneromooo> Yes, or shortly before it finishes a full sync.
15:59:55 <bigslim[m]> Dammit
16:01:07 <moneromooo> It doens't tell you *that* much. How much data was dud, how much was redundant, how much time it spent waiting for blocks to add (that one is interesting).
16:02:16 <bigslim[m]> Socket error 10051
16:02:29 <bigslim[m]> Just got that exiting daemon. Never seen that before
16:27:42 <bigslim[m]> The latest blocs are definitely very slow. Those last 13k just looking go very very very slow compared to older RingCT blocks
16:28:17 <sethsimmons> That’s because you’re past the checkpoint at that point and doing 100% verification.
16:28:36 <sethsimmons> And of course we’ve had lots of full blocks so more transactions to validate
16:28:36 <bigslim[m]> Yea. When’s the latest checkpoint
16:28:50 <sethsimmons> Not sure, it gets bumped with each release
16:29:33 <bigslim[m]> I would hope it’s fairly close to recent tx levels especially with all these full blocks the last 6mo
16:30:49 <moneromooo> Last blocks all get PoW checked. If you run a prebuilt binary, these come with a set of known good hashes to skip PoW for most of the history.
16:31:05 <moneromooo> (that's what --fast-block-sync 0 disables)
16:34:40 <sethsimmons> Latest run on 1950X/32GB/1TB NVMe SSD w/ lots of background processes/nodes running is: 3h 41m 30s
16:34:48 <sethsimmons> Thats with 100% defaults, nothing set
16:34:59 <sethsimmons> <moneromooo "It was: set_log +sync_info:INFO"> This didn't tell me anything extra for some reason
16:35:23 <selsta> sethsimmons: so out_peers does not matter?
16:35:29 <selsta> or not in this case?
16:35:48 <sethsimmons> Sorry this is a different test
16:35:50 <sethsimmons> Different hw
16:35:59 <sethsimmons> Other test of just out_peers is running now.
16:36:06 <selsta> ok
16:36:11 <moneromooo> pop 50 blocks, exit, restart with --log-level 0,sync_info:INFO.
16:36:44 <moneromooo> It might not tell you anything if it's already hit the "I'm synced" case before, which it can if it only finds partially synced peers, and fully synced peers later on.
16:38:30 <sethsimmons> I ran it right after starting the sync from scratch
16:38:39 <sethsimmons> Testing again, if it fails again I’ll try popping
16:43:12 <moneromooo> Odd, it doesn't show up, but shows up with 0,sync-info:INFO, though the code looks like the former should work...
16:43:38 <moneromooo> It shows: Sync time: 0.295644 min, idle time 32.6267%, 1.6 + 0 MB downloaded, 0% old spans, 0% bad spans
16:46:03 <moneromooo> Well, I guess set log level 1 to shortly before end of sync :) Not sure why...
16:49:27 <sethsimmons> <moneromooo "Well, I guess set log level 1 to"> I’ll try that!
17:02:55 <moneromooo> My god, I'm just a total fuckwit, and after adding traces to debug, I now realize it's sync-info and I typed sync_info. Go me.
17:03:03 <moneromooo> Works now.
17:03:57 <Mochi101> You were just being consistent.
17:04:17 <moneromooo> Small blessings...
17:04:45 <Mochi101> Is that the only command that uses an - instead of an _
17:06:03 <moneromooo> It's not a command, it's a log category, and it looks like it.
17:08:13 <bigslim[m]> Seth so you synced in under 4hrs? Wtf
17:08:22 <bigslim[m]> But thats Linux right?
17:08:57 <selsta> Windows apparently
17:10:21 <moneromooo> Must a Windows VM on linux then.
17:10:23 * moneromooo runs
17:14:14 <sethsimmons> <bigslim[m] "Seth so you synced in under 4hrs"> Yup, 3h41m on Linux (Ubuntu server 20.04)
17:14:31 <sethsimmons> My other rig is Windows/3700X and I'm testing that right now to compare the effect that out_peers has.
17:14:49 <sethsimmons> <sethsimmons "Yup, 3h41m on Linux (Ubuntu serv"> Re-running this with out_peers 50 to compare as well, first run was just all default (so out_peers 8)
17:15:32 <sethsimmons> <moneromooo "My god, I'm just a total fuckwit"> ohh thats really nice
17:15:41 <sethsimmons> Going to add that by default when doing IBD from now on
17:15:42 <sethsimmons> Great stats!
17:17:41 <sethsimmons> Looks like I regularly run out of queued blocks on the out_peers 8 machine ATM, and always have ~50MB queued blocks on the out_peers 50
17:18:05 <sethsimmons> 20-50MB to be more precise in reality from what I'm seeing
17:20:09 <moneromooo> By default, the queue gets 100 MB or 20 spans, whichever is reached second.
17:23:04 <Inge-> how do you see the queue?
17:23:24 <moneromooo> sync_info
17:23:49 <moneromooo> (yes, that one has a _, it's a command, and probably why I mixed up the category)
17:34:08 <bigslim[m]> Am I the only one who lazily uses windows for crypto?
17:34:31 <bigslim[m]> Would be interesting to see how someone else syncs on windows
17:35:31 <moneromooo> iDunk definitely unlazily uses windows, and had really fast sync times. Then again, he was my test case when I wrote that code :)
17:35:45 <bigslim[m]> Hmm
17:36:07 <bigslim[m]> Now I’m bugged and want to see why it is so slow for me
17:36:33 <bigslim[m]> I mean it’s 80% faster than v0.14 so def an improvement
17:41:09 <sethsimmons> I mean I’m syncing on windows and got less <4h
17:41:12 <sethsimmons> 3700X/16GB/1TB NVMe SSD
17:41:26 <sethsimmons> It’s not a windows issue on an OS level, but maybe some config on your specific host
17:42:02 <moneromooo> Maybe run a Linux-from-DVD distro, sync and see it becomes fast all of a sudden.
17:42:17 <moneromooo> Might have to partition the disk a bit though I guess.
17:58:59 <nioc> <bigslim[m]> Socket error 10051
17:59:00 <nioc> Just got that exiting daemon. Never seen that before  <-> for quite a while I have been getting this occasionally
17:59:09 <nioc> and yes I use windows
17:59:23 <nioc> but then again I am clueless
18:06:00 <bigslim[m]> Not sure what configs it would be. It’s just windows installed. Nothing special really. Also have this set to the highest level of QOS from router so it gets priority
18:10:06 <sethsimmons> Yeah he’s to track down... you could try again with the sync-info like above and see if it seems to be waiting on something in particular, but honestly no idea since mine syncs so much more quickly on similar/worse hardware.
18:10:15 <sethsimmons> * Yeah hard to track down... you could try again with the sync-info like above and see if it seems to be waiting on something in particular, but honestly no idea since mine syncs so much more quickly on similar/worse hardware.
18:13:35 <d4ndo[m]> I would like to have some sort of signed csv file from localmonero.co. This way i have a proof if necessary. Most trades in cash dont have a receive.
18:16:17 <d4ndo[m]> An anonymous version would be ok. signed with their gpg key. The key could still be public even in case of insolvency.
18:18:38 <d4ndo[m]> aml should not exist. You need to prove your innocence.
18:18:46 <d4ndo[m]> Bullshit law.
18:19:20 <d4ndo[m]> It started in the 90s
18:20:10 <d4ndo[m]> and was slowly getting stricter and stricter.
18:20:48 <d4ndo[m]> In March the used the pandemic to make the law even more strict.
18:21:25 <d4ndo[m]> Now every illigal activity is a reason. they startet with drugs.
18:22:08 <d4ndo[m]> I think March 2020 the aml law changed in the U
18:22:11 <d4ndo[m]> eu
18:46:59 <sethsimmons> https://reddit.com/r/Monero/comments/jajm84/cli_v01710_oxygen_orion_has_been_tagged_you_may/
18:49:17 <selsta> sethsimmons: GUI v0.17.1.0 will soon be tagged as well.
18:49:18 <selsta> it already is
18:49:19 <selsta> :D
18:59:10 <sethsimmons> 😳 updating!
18:59:56 <sethsimmons> Should I make a similar post for gitian builds of those?
19:00:16 <dEBRUYNE> No gitian builds yet for the GUI
19:04:57 <sethsimmons> Thanks
19:10:16 <binaryFate> Please make a PR to gitian repo if you can, they're signed and reasonably immutable. Hashes on reddit are better than nothing for sure, but posts can be edited forever after and do not provide accountability. I'd rather have sufficient publicly accountabile proof of who vetted particular hashes.
19:11:32 <binaryFate> Of course it's a more complicated process, so if people just post on reddit it's great and their participation is very welcomed nonetheless. But those who know how to do the gitian workflow, please make the extra step <3
19:12:01 <cbr> Just compiling xmrig on a solar powered raspberry pi 4 for a laugh
19:12:13 <cbr> expectig about 4h/s lol
19:14:59 <cbr> was not worth the sunlight and wear on the motorbike battery overnight backup on the old algo before randomx
19:15:54 <dEBRUYNE> sethsimmons: Perhaps we can add that to the thread, i.e., request for people to open a PR as well to the gitian sig repo
19:19:23 <dixie__flatline[> cbr: let the hashes roll
19:19:32 <dixie__flatline[> for the decentralization of hash power
19:19:36 <dixie__flatline[> every cpu counts
19:19:52 <cbr> 29% cmake progress
19:20:00 <cbr> been going 30 mins lol
19:20:15 <cbr> 31
19:20:18 <cbr> speeding up
19:22:46 <cbr> probably kill the 64gb class 10 sd card but worth it if there is zero electric cost
19:23:42 <cbr> built the solar/battery supply originally for boinc, expect the lack of a L3 cache with perform awful on RX
19:32:40 <cbr> OclWorker.cpp:(.text+0x35c): undefined reference to `__atomic_load_8'
19:32:47 <cbr> oh well worth a go lol
19:36:42 <cbr> might be libuv missing , start compile again
19:39:35 <cbr> If anyone is as sad as me the solution seems to be cmake .. -DCMAKE_BUILD_TYPE=Release -DARM_TARGET=7 -DWITH_OPENCL=OFF -DWITH_CUDA=OFF -DWITH_HWLOC=OFF -DWITH_TLS=OFF -DWITH_ASM=OFF
19:39:35 <cbr> ; make -j 4 --environment-overrides --keep-going
19:58:04 <Inge-> Is Atomic Wallet another one of the selective scams, or legit?
19:59:09 <kayabaNerve> If you don't select XMR, you get scammed into using a coin which forfeits your privacy /s
19:59:40 <kayabaNerve> *I don't actually know. I've heard decent things about the wallet itself, yet I've also heard it was founded by someone working at Changelly at the time, which isn't exactly XMR-friendly
19:59:57 <dEBRUYNE> Their CEO is the founder of Changelly iirc
19:59:57 <kayront> changelly are very XMR friendly
20:00:05 <kayabaNerve> They are?
20:00:07 <kayront> they like it so much, they'll steal yours!
20:00:11 <kayabaNerve> Lol
20:00:25 <kayabaNerve> So not XMR community friendly :P
20:00:37 <kayront> can't reasonably argue that point :p
20:01:20 <Inge-> I sometimes feel like we are scarred from knowing too much about lack of privacy in other coins. Like the agricultural researcher who won't eat ground meat because he knows so much about bacterial growth - I have a hard time transacting in panopticoins
20:01:37 <kayront> yes
20:01:47 <kayront> when you understand the implications, you tend not to
20:01:52 <kayront> (transact)
20:02:02 <kayront> panopticoins - lol, even better than surveillance coin
20:03:57 <Inge-> I thought I coined it
20:04:04 <Inge-> But go to youtube and search for panopticoin
20:04:27 <Inge-> pretty good talk. 5 years old ...
20:04:39 <Inge-> talking about the problem with bitcoins public ledger
20:06:01 <kayabaNerve> Should I feel bad for my work on transparent coins? :(
20:06:40 <kayront> at least 10 daily floggings
20:07:05 <kayront> and confess here once a week
20:07:05 <kayront> should be fine..
20:07:27 <hyc> why would you be in this channel, and work on transparent coins...
20:07:52 <kayront> of course, you can also donate to our group who helps people just like you! it's called panopticoiners anonymous. pm for xmr addr
20:08:05 <copenhagen_bram[> for the same reason a former christian looks into atheism?
20:09:48 <Inge-> That sounds off
20:10:44 <kayabaNerve> kayront: Does confess mean shill while claiming to be part of the church of monero?
20:11:06 <kayront> it means whatever you wish it to mean to purify your immortal soul™ kayabaNerve
20:11:21 <kayront> praise the fluffy
20:11:40 <kayabaNerve> hyc: Because I'd like to believe my work matters, don't have the skills to implement RingCTs, and could do CTs with BPs but I'm not sure what privacy mechanism I want to select in the future
20:11:45 <kayabaNerve> Also time crunch and all that
20:12:32 <kayabaNerve> *I'm not stupid enough where I can't copy out the libringct library. I wrote out its API a while back so I could directly call it to generate signatures. Was fun.
20:13:08 <kayabaNerve> But I don't feel a need to cram them in there when I don't have the relevant skills
20:13:53 <copenhagen_bram[> Why doesn't Monero work with the Trezor One?
20:14:22 <kayabaNerve> copenhagen_bram[: Somewhat ironically, I am religious :P Not an athiest though, yet I do know all the reasons against organized religion, supernatural beings in general, and respect their views.
20:14:36 <selsta> Ask Trezor. Most likely the device is not strong enough or they simply didn’t add support.
20:16:35 <copenhagen_bram[> Hmm. Now why isn't there a hardware wallet with some kind of API that allows any cryptocurrency to be stored with it? As in the hardware wallet doesn't support X cryptocurrency, X cryptocurrency supports the hardware wallet.
20:19:06 <asy> copenhagen_bram[: crypto ops need to happen on the device, so that it can do what it needs to do without revealing the key to the host
20:19:35 <asy> and it's useful for the device to understand what's going on, so that it can show something like "sending 1 XMR to 41zih.... Accept/Cancel"
20:24:11 <dEBRUYNE> copenhagen_bram[: Device doesn't have enough resources if I recall correctly
20:25:17 <copenhagen_bram[> Ah, okay.
20:51:57 <sethsimmons> <dEBRUYNE "sethsimmons: Perhaps we can add "> Done
20:54:41 <dEBRUYNE> ty
21:01:53 <viperperidot[m]> Has anyone had issues with really slow blockchain sycning?
21:02:10 <viperperidot[m]> I'm using an ssd with a decent internet connection and it is still very slow
21:02:55 <viperperidot[m]> Currently going to take 28 days to sync at this pace and I am already at 67% of the chain
21:04:08 <selsta> which version?
21:04:17 <viperperidot[m]> 0.17.0.1
21:04:35 <selsta> How long did it take to get to 67%?
21:05:12 <lza_menace> nope
21:05:33 <viperperidot[m]> That took around 2 days and then it came to a snails pace after that
21:05:36 <viperperidot[m]> For some reason..
21:06:05 <viperperidot[m]> Am I getting throttled by my isp?
21:07:03 <moneromooo> Run sync_info in monerod. If the overview string starts with mooo, you're good. Check every once in a while.
21:07:20 <lza_menace> I stood up a new vps a few days ago and bootstrapped a 0.17.0.1 node, took a few hours
21:07:29 <lza_menace> i didn't really babysit it though, just walked away
21:07:32 <moneromooo> o means "I have this span", m means it matches what you need next, . means requested from a peer but don't have it yet.
21:08:34 <viperperidot[m]> [moooooooooooooooooooooooooo.]
21:08:47 <viperperidot[m]> Is that what you mean?
21:09:49 <viperperidot[m]> That's what it says around the middle of my sync_info message
21:11:32 <moneromooo> So you're not waiting on your network.
21:11:35 <moneromooo> Yes.
21:11:58 <moneromooo> Run top, check what's it's doing. us (user), wa (I/O), other
21:12:01 <moneromooo> Third line.
21:12:09 <viperperidot[m]> Ok I have synced 380 blocks in 23 minutes
21:12:14 <selsta> Is it external SSD / network share?
21:13:32 <viperperidot[m]> <moneromooo "Run top, check what's it's doing"> I don't see the top command on monerod?
21:14:12 <viperperidot[m]> <selsta "Is it external SSD / network sha"> It is an external ssd I don't think it is local network share
21:14:20 <viperperidot[m]> Should I enable that?
21:14:30 <selsta> No
21:14:48 <selsta> External SSD will most likely have slow seek I guess?
21:17:07 <viperperidot[m]> <moneromooo "Run top, check what's it's doing"> us 16.0, wa 1.6
21:17:34 <moneromooo> Is monerod at ~100% CPU ]>?
21:17:56 <sethsimmons> bigslim: Sync from scratch with 50 out_peers on 1950X/32GB/1TB NVMe SSD took 239m (3h59m):
21:17:56 <sethsimmons> Sync time: 239.361 min, idle time 45.7021%, 69172.3 + 875.3 MB downloaded, 2.13073% old spans, 0% bad spans
21:17:56 <moneromooo> wa 1.6% is not much.
21:18:20 <moneromooo> That's a lot of idle time...
21:19:42 <viperperidot[m]> monerod is at 0.6% cpu
21:21:03 <viperperidot[m]> <moneromooo "Is monerod at ~100% CPU ]>?"> ^
21:22:11 <moneromooo> Can you paste the entire line with %wa from top ?
21:22:27 <moneromooo> wa, us, sy etc
21:24:49 <viperperidot[m]> %Cpu(s):  6.9 us,  2.2 sy,  0.0 ni, 67.4 id, 22.8 wa,  0.0 hi,  0.7 si,  0.0 st
21:25:07 <viperperidot[m]> moneromooo: ^
21:27:24 <viperperidot[m]> I should note that I originally was syncing onto my laptop hdd and it was going pretty well and then around 2 days at 44gb it became seriously slow and basically froze my laptop, so that's when I copied the blockchain over to the ssd thinking that it would speed up again but it hasn't..
21:27:25 <moneromooo> 22.8% is a lot more than 1.6.
21:27:53 <moneromooo> 22.8% means it's stuck on disk I/O.
21:28:11 <moneromooo> Are you sure you used --data-dir to point to the SSD ?
21:29:08 <viperperidot[m]> I am using the GUI and selected the ssd folder location by clicking the 'change' button
21:29:23 <viperperidot[m]> it is under /media
21:30:02 <viperperidot[m]> Do I need to add something to the daemon startup flags?
21:30:16 <moneromooo> The GUI probably does it right.
21:30:34 <moneromooo> I guess the mount is just slow...
21:31:04 <viperperidot[m]> Dammit I specifically bought this ssd for syncing the blockchain faster lol..
21:31:33 <moneromooo> Wait for someone who has a clue about hardware differences :)
21:32:51 <viperperidot[m]> I don't see monerod in top anymore o.o
21:33:15 <moneromooo> Do you see kswapd near the top ?
21:33:30 <moneromooo> Or rather, what do you see up top ?
21:34:15 <viperperidot[m]> no kswapd
21:34:59 <viperperidot[m]> monero-wallet-g is #1 around 13% cpu
21:37:44 <viperperidot[m]> I'm never going to be able to use monero at this rate XD
21:37:59 <viperperidot[m]> I don't get it, it's not like i'm using bad hardware or have slow internet..
21:38:36 <selsta> I guess the problem is that the SSD is external
21:38:42 <selsta> is it using USB?
21:38:53 <viperperidot[m]> monerod is not running in top yet someone I still get blocks
21:39:12 <viperperidot[m]> Yes usb
21:39:16 <sethsimmons> Of
21:39:19 <sethsimmons> *oof
21:39:22 <sethsimmons> That would be why
21:39:33 <sethsimmons> USB (even 3.0) can’t support an SSDs speeds.
21:39:51 <viperperidot[m]> But it was just as slow when using the hdd on my laptop
21:39:57 <sethsimmons> Can you replace the laptops HDD with the SSD?
21:40:15 <sethsimmons> Almost all laptops use 2.5” drives and almost all SSDs are 2.5”
21:40:20 <sethsimmons> But obviously depends
21:40:33 <sethsimmons> An SSD will do wonders for your day to day usage of a laptop as well
21:40:33 <viperperidot[m]> How else would someone connect an external ssd without usb?
21:40:59 <sethsimmons> Sometimes sata but yeah, normally just USB is available
21:41:14 <viperperidot[m]> This is an external ssd so I don't think I can put it in my laptop
21:41:15 <sethsimmons> It’s just a very poor transfer layer for anything serious
21:41:28 <viperperidot[m]> plus I would have to reinstall my os and everything if I switch storage..
21:41:36 <sethsimmons> It can come out of the case ;) but if you’re not comfortable I probably wouldn’t do that lol
21:42:24 <viperperidot[m]> I don't know this is a metal cased on it would probably be hard to get out lol
21:42:26 <viperperidot[m]> one*
21:43:19 <viperperidot[m]> But if you use a raspberry pi as your node you will most likely be using an external ssd with usb as well right?
21:43:41 <strike> do you have a wifi card or another M.2 slot? they make M.2 to SATA adapters, you could attach your drive to that
21:48:14 <sethsimmons> Honestly if you could take it back and just buy an internal SSD that would be cheaper and faster
21:48:33 <sethsimmons> If not, there’s not much you can do to increase sync speed over USB
21:48:47 <viperperidot[m]> I don't think I have an M.2 slow but not sure what they look like
21:48:49 <sethsimmons> (That I know of, at least)
21:48:53 <viperperidot[m]> the only slot I see on my laptop is an sd card
21:49:13 <sethsimmons> M.2 would be an internal slot, so not helpful for connecting an external SSD temporarily.
21:49:22 <strike> viperperidot[m]: its going to be on your laptop's motherboard
21:50:21 <dEBRUYNE> <sethsimmons> USB (even 3.0) can’t support an SSDs speeds. <= External SSDs can still sync relatively fast
21:50:23 <strike> sethsimmons: its more of a hassle for sure
21:50:25 <dEBRUYNE> Speaking from personal observation
21:50:33 <sethsimmons> Good to know
21:50:37 <viperperidot[m]> Yeah I don't want to reinstall my os and applications and everything and replace my hdd with an ssd just to sync the blockchain
21:50:44 <sethsimmons> I would never recommend one but expected them to be very slow
21:50:44 <dEBRUYNE> 380 blocks per 23 minutes is extraordinarily slow
21:50:48 <dEBRUYNE> It shouldn't happen
21:51:00 <sethsimmons> Wow didn’t see those numbers
21:51:08 <sethsimmons> That’s not possible unless you have no peers I don’t think
21:51:14 <sethsimmons> s/no/few
21:51:51 <viperperidot[m]> Yeah there must be something wrong for it to be this slow but I don't know what..
21:51:58 <viperperidot[m]> This is my first time trying to sync monero
21:52:25 <viperperidot[m]> It was going fine for a couple days then something happened and its just terrible now
21:52:40 <sethsimmons> Do you have peers?
21:52:40 <sethsimmons> Run “status” on monerod
21:53:30 <selsta> moo analyzed it and it was not network related
21:53:37 <sethsimmons> Hmm
21:54:28 <moneromooo> You can: set_log +perf*:DEBUG
21:54:42 <moneromooo> Timings will show up in your log file. You can see what's taking time.
21:54:56 <moneromooo> But at 22% wa, it's going to be the disk.
21:55:16 <viperperidot[m]> If this information helps, I have 8 peers but all of them say 0MB queued except for 1 peer
21:55:30 <sethsimmons> One last idea: viperperidot are you sure its an external SSD and not a “hybrid” hard drive or similar? Can you share the model by any chance?
21:55:50 <moneromooo> That's a bit odd.
21:56:15 <viperperidot[m]> I have 102mb queued from 1 peer and the rest are 0
21:56:23 <moneromooo> Oh, OK. Good.
21:56:46 <moneromooo> It's odd it's not more varied, but 100 MB is what it aims to have
21:57:36 <viperperidot[m]> <moneromooo "But at 22% wa, it's going to be "> You mean the ssd?
21:57:58 <viperperidot[m]> <sethsimmons "One last idea: viperperidot are "> It is a Samsung portable ssd T7
21:58:50 <moneromooo> Yes.
21:59:15 <viperperidot[m]> samsung t7 500gb usb3.2 gret external solid state drive
21:59:20 <viperperidot[m]> grey*
21:59:26 <sethsimmons> <viperperidot[m] "It is a Samsung portable ssd T7"> And its in a USB3 port, I would assume? That’s a fancy external SSD :P
21:59:43 <sethsimmons> Unless you have a very recent laptop its likely not going to be 3.1/3.2, but at least 3.0 hopefully.
22:00:28 <viperperidot[m]> Yeah I know it's fancy I friggin bought a good one because I wanted it to sync the blockchain faster!!! lol ffs
22:00:45 <viperperidot[m]> I'm not sure if my laptop has 3.0 usb
22:00:54 <viperperidot[m]> it's a couple years old
22:00:57 <sethsimmons> <viperperidot[m] "I'm not sure if my laptop has 3."> Are any ports blue?
22:01:27 <viperperidot[m]> No they are black
22:01:49 <sethsimmons> What model laptop (if you don’t mind)? I would doubt if its only 2y old that it wouldn’t have USB3.
22:03:47 <viperperidot[m]> What's the command in linux for finding your model number?
22:04:03 <sethsimmons> Just look on the bottom of your laptop, usually a sticker there has the model
22:04:11 <sethsimmons> Or perhaps along the bezel of the display
22:04:28 <viperperidot[m]> Dell Inspiron 15
22:04:31 <sethsimmons> The model may or may not be passed correctly to Linux (and Idk how to see it)
22:04:48 <sethsimmons> <viperperidot[m] "Dell Inspiron 15"> Is there a more specific model number that’s longer? Like 15U700 etc?
22:05:01 <sethsimmons> They’ve used that naming scheme for many years so that can mean a lot of different laptops :)
22:08:33 <viperperidot[m]> Inspiron 15-3567
22:09:41 <viperperidot[m]> I have ordered a raspberry pi and was planning on setting it up as a monero remote node, so do you guys think if I use the same ssd with the usb 3.0 port on the pi it will be faster than this?
22:10:48 <strike> usb C/3.1 would be faster
22:11:09 <sethsimmons> It has 2x USB3.2 ports
22:11:26 <sethsimmons> They should be distinguished with a “SS” or similar above or besides the port viperperidot
22:11:48 <sethsimmons> Looks like the two ports on the left side are USB3.2
22:12:04 <viperperidot[m]> <strike "usb C/3.1 would be faster"> Right I think I have the cord for that too
22:12:28 <viperperidot[m]> <sethsimmons "Looks like the two ports on the "> Ok well that's the port i'm using
22:12:35 <sethsimmons> C isn’t natively faster than A, it’s still using the same busses and your laptop has USB3.2 USBA
22:12:44 <sethsimmons> <viperperidot[m] "Ok well that's the port i'm usin"> Thought we were on to something 😭
22:12:49 <viperperidot[m]> I have been syncing for 1 hour and 8 minutes and I have synced 1480 blocks......
22:12:49 <sethsimmons> I’m not sure past that honestly
22:14:14 <viperperidot[m]> Is it possible that my isp is throttling me?
22:14:34 <viperperidot[m]> This is some bullshit lol dammit
22:14:45 <viperperidot[m]> I wanted to buy some xmr this week
22:15:53 <moneromooo> Possible, but it's not your problem based on what sync_info said.
22:17:12 <viperperidot[m]> Right
22:17:25 <viperperidot[m]> It's weird that the hdd and ssd had the same speed though
22:18:30 <moneromooo> Sure is. Did you triple check the size of the db on the SSD and the old one on your HDD (if you've not deleted it) ?
22:18:40 <moneromooo> Just to make really really sure it's going to the SSD :)
22:20:04 <viperperidot[m]> Yes the db on my ssd is 44.7gb and on my hdd it's 44.4
22:20:33 <viperperidot[m]> The nice thing about the ssd though is that it's not making my computer freeze when syncing
22:21:29 <viperperidot[m]> I guess i'll just leave it running 24/7 until my pi gets here, then switch to the pi. If it doesn't speed up with the pi then i'll wait 1 month before I can buy my first xmr after I have synced XD.
22:22:10 <moneromooo> Did you try set_log perf*:DEBUG ?
22:22:22 <viperperidot[m]> Shit sorry I forgot to do that
22:22:23 <viperperidot[m]> one second
22:22:36 <moneromooo> Do it, then wait two "Sycned: X/y" lines, then check the log.
22:30:30 <viperperidot[m]> Am I supposed to see something in the log after setting that?
22:32:04 <moneromooo> Yes, lines with PERF in them,
22:32:10 <moneromooo> In the log file, not the console.
22:34:19 <viperperidot[m]> Can I look at it through the Daemon log in the GUI or?
22:34:30 <moneromooo> Probably.
22:34:36 <selsta> ~/.bitmonero/bitmonero.log
22:34:39 <selsta> or so
22:34:50 <moneromooo> Or /media/.... somewhere
22:34:59 <selsta> right
22:35:21 <viperperidot[m]> Ok got the log file
22:35:36 <viperperidot[m]> It is still in /.bitmonero
22:35:45 <viperperidot[m]> Because I only moved the db into thr ssd
22:35:45 <viperperidot[m]> the*
22:37:12 <viperperidot[m]> I see a bunch of warnings, fatal and errors...
22:37:21 <viperperidot[m]> lol this can't be good
22:38:25 <selsta> what is the timestamp of the log?
22:38:28 <selsta> is it recent?
22:38:41 <selsta> afaik setting --data-dir should also move the log
22:38:49 <selsta> or create a new one in the new location
22:38:58 <viperperidot[m]> Oh ok let me check
22:40:11 <viperperidot[m]> Ok sorry I am in the correct log now
22:40:15 <viperperidot[m]> This looks better
22:40:21 <viperperidot[m]> What info would you like to see?
22:43:26 <selsta> viperperidot[m]: are there lines with PERF in them?
22:43:31 <viperperidot[m]> Yes
22:43:44 <selsta> mooo knows what to do with them
22:44:16 <moneromooo> Paste a good contiguous chunk to paste.debian.net
22:44:48 <moneromooo> Ideally, all the one between the last two "Synced: X/Y" lines.
22:50:52 <viperperidot[m]> moneromooo: I tried pasting more but it exceeded the size limit, let me know if you need more : https://paste.debian.net/hidden/02832134
22:52:14 <moneromooo> get_info is being ridiculously slow here.
22:52:36 <moneromooo> Coming from the GUI, most likely. If you're running it, exit, and let the daemon sync alone.
22:53:07 <moneromooo> Then run "monerod status" from time to time to see whether it goes faster.
22:53:16 <viperperidot[m]> Yes I had the GUI open the whole time
22:53:21 <viperperidot[m]> Ok I closed it now and will try that
22:54:56 <viperperidot[m]> do I have to run the monerod shared library file to use this command?
22:55:38 <moneromooo> Then again, it looks like it might just have been waiting for monerod do its thing.
22:56:02 <moneromooo> The timestamps looks like it's very slow, but the timings on the actual work aren't particularly bad.
22:56:52 <moneromooo> So could be, I dunno, disk flushes from time to time, stopping the whole thing.
23:00:23 <viperperidot[m]> Not sure how to get the monerod command working
23:00:43 <selsta> ./monerod status
23:02:00 <viperperidot[m]> Thanks
23:04:58 <viperperidot[m]> 2020-10-13 23:04:29.417	I Monero 'Oxygen Orion' (v0.17.0.1-release)
23:04:58 <viperperidot[m]> Height: 1498787/1498787 (100.0%) on mainnet, not mining, net hash 731.52 MH/s, v6, 8(out)+0(in) connections, uptime 0d 2h 15m 44s
23:05:11 <viperperidot[m]> Now it thinks i'm 100% for some reason
23:05:22 <selsta> wait a few minutes and try again
23:06:34 <viperperidot[m]> Ok well let me know if you have some kind of revelation about this moo
23:06:37 <viperperidot[m]> Thanks for the help
23:06:45 <viperperidot[m]> I'll see if closing the gui helps
23:07:02 <nioc> net hash is no where near correct
23:07:57 <viperperidot[m]> Yeah I noticed before it was in the kh/s range which was obviously wrong
23:08:04 <selsta> nioc: net hash is not correct until sync afaik
23:08:13 <nioc> ok :)
23:08:48 <monerouser1144> Sorry if it has been discussed, but I just dropped by to ask about the huge spike in hashrate as evidenced at https://miningpoolstats.stream/monero
23:08:51 <moneromooo> It should be.
23:11:56 <nioc> just tried syncing a node I rarely use, shows 1.22 GH/s which is correct
23:13:02 <nioc> wait no it's not
23:13:08 <nioc> carry on
23:13:21 <moneromooo> It shows 1498787/1498787, so it thinks it's syunced.
23:13:48 <moneromooo> That's very odd, and might explain why it's so slow, if it stops, then starts syncing a little but more, then stops again, etc.
23:14:29 <moneromooo> What's the output of sync_info, just the peers list (should be 8 lines) ?
23:25:46 <viperperidot[m]> No there is more info than that
23:26:02 <viperperidot[m]> I can pastebin it
23:26:12 <moneromooo> I mean I only need the peers list, not the rest.
23:26:40 <viperperidot[m]> Ok 1 second
23:29:00 * viperperidot[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/GqKWUndAXHiKfwNalrBIXmjv/message.txt >
23:29:06 <viperperidot[m]> Right now I have nothing coming in
23:29:29 <moneromooo> Ah...
23:29:33 <moneromooo> You got fucked by asshole nodes.
23:29:42 <viperperidot[m]> LMAO
23:29:44 <viperperidot[m]> what?!
23:29:47 <moneromooo> Exit monerod. Delete p2pstate.bin. Restart.
23:30:05 <moneromooo> Some nodes are cunts, and lie. They point to each other, so you end up connecting only to them.
23:30:30 <moneromooo> So deleting p2pstate.bin means you'll try to get more nodes off (hopefully) honest seed nodes.
23:38:11 <moneromooo> Does it help ?
23:38:47 <moneromooo> Paste your peer list from sync_info after you've restarted with a fresh p2p state.
23:41:37 <viperperidot[m]> seems to still be slow but at least it does not think I am at 100% anymore
23:41:59 * viperperidot[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/SyuhMXGIurDOuFRXhSQCdDXt/message.txt >
23:42:30 <viperperidot[m]> Got 2.7mb coming in
23:43:10 <moneromooo> Strill hav some assholes. Two seem not to be.
23:43:18 * moneromooo afk for a bit
23:43:29 <viperperidot[m]> What's up with these assholes
23:43:39 <viperperidot[m]> Should I just keep restarting until I get good ones?
23:43:55 <viperperidot[m]> That would make sense why it randomlly got slow one day if I just connected to the wrong nodes
23:44:04 <viperperidot[m]> How do you know if a node is an asshole?
23:45:08 <selsta> you can go to e.g. xmrchain.net to see the correct block height
23:45:42 <selsta> and if your target block height says something completely different it could be the case that all your peers are lying, though that never happened to me yet
23:49:04 <nioc> selsta: is it true that you just need 1 honest node?
23:49:18 <selsta> I don’t know really how that works :)
23:49:39 <nioc> think that's wat mooo has said