12:34:32 Hi I have a question about sync time with monero-gui on Mac. It's been running for two days and the bar progresses but it doesn't seem to make headway. Will it ever get to the end or are transactions being added so fast that I should have selected prune the blockchain? 12:37:24 Can you go to the Settings page -> Log tab, type status, and post the output here? 12:39:31 [12/09/2023 14:37] 2023-09-12 12:37:52.999 I Monero 'Fluorine Fermi' (v0.18.2.2-release) Height: 2624212/2972573 (88.3%) on mainnet, not mining, net hash 2.75 GH/s, v14, 12(out)+0(in) connections, uptime 1d 17h 50m 24s 12:43:00 Does that help? 12:43:53 If your mac doesn't have ssd, it can take a week 12:44:10 It's still synchronizing 12:49:02 It has a new ssd a good one but its a 2013 trash can so the pci-e is gen 2 I guess. Glad to know it is normal to take a good amount of time 12:49:04 Thanks 12:59:47 drinternationale: Do you see also the block numbers? I don't see it in your output 13:23:04 The total or current? I copied everything from the status command output down. It showed something like 375k blocks left when I left the house just. I was concerned because it went from over 1m blocks to 375k rather fast maybe in 12 hours then appears to fluctuate around this 375k ever since. There is around 800 gb free on the ssd and the computer doesn't sleep or something silly like that. 13:26:35 It's a 12 core xeon with 64gb ram. I'm new to monero. So sorry if it's tmi I don't know what is relevant and not 13:27:35 It shouldn't fluctuate, the first number in 2624212/2972573 should go up steadily 13:29:59 I'm going off blocks left as that is what I remembr ill look for the other when I'm back home. Thank you so much for the help 13:37:45 Yes I see 2652292/2972605 now 13:39:03 It was the Daemon blocks remaining that seemed to slow down and fluctuate between 11 pm last night and around 2 pm this afternoon. It has gone down to 318354 now which correlates with the status output. 13:41:42 `sync_info` 13:41:42 what does the `moooooooo` line look like 13:44:02 this ? [mooooooooooooooooooooooo.oo....] 13:44:08 Yes 13:44:09 What in goodness is that? 13:44:12 Looks good. 13:44:26 It shows blocks queued / syncing 13:44:29 This made me chuckle. 13:44:31 Okkkk 13:45:11 Each letter is a batch of blocks. If the m is missing, stalled. Sometimes youll have a lot of missing letters, usually from being sent bad blocks. 13:45:19 But looks good. Should be syncing properly 13:45:43 Oh wow that's brilliant thank you so much ofrnxmr 13:46:09 thank moneromoooo: :) 13:46:56 Its very rare that you get a good moooooo from a piece of software these days 13:48:21 indeed. Looks like ~30k blocks per hr syncing right now 13:48:51 about 10-12hrs remaining 13:50:02 I am only doing it to see what the hash rate is like on such an old computer. Then I will try running on my shiny new etc 4070Ti :o) 13:50:18 Gpu = no good 13:50:21 What is the bottle neck with syncing. I assume its not download its the verification of each block? 13:50:46 Oh Really 13:51:13 I thought it was resistant to ASICs meaning GPU and CPU miners better 13:51:13 typically io is the major bottleneck, but i think sech1 said there may be a multithreading issue 13:52:23 ohhh for sync not mining 13:52:29 Okok 13:53:07 .. i dont think we use gpu for verification. Someone else will have to comment on that 13:55:06 Yeah looks like at least the OSX version its threaded but its bottle necked at IO \ 13:59:15 ofrnxmr is correct about GPU. 14:01:14 It that because of the type of algorithm you use for the verification? I am by no means a developer but I find it fascinating. 14:01:28 Yes. 14:02:01 Verification is one program working on one set of data. GPUs are good for a program working on many sets of data in parallel. 14:03:22 Where can I read about this best? I have lots of questions but they are mostly interest related and I don't want to take everyones time or derail the chat. 14:05:45 Try monero.stackexchange.com. 14:06:02 Thank you kindly 14:06:15 Or, for specifics, start with the discussion for the randomx PR on github. 14:07:03 SIMD is a good keyword for generalities. 14:07:11 Super I think that's what I am looking for. 14:07:48 Fragment programs/shaders might also get you interesting stuff, that's application of GPU's strength to graphics. 14:08:52 And AI nowadays. Lots of matrix math. Very SIMD. 14:09:08 Well, some AI is. Like SVMs. I dunno about more recent LLM stuff. 14:10:09 I am interested to understand why for instance the verification algorithm can't be done on the GPU. I am learning C++ slowly and I am ok with Python. It's all very fun thank you so much. Moneromoo 14:11:59 It can be done. It will just be slow. 14:12:54 You need to upload a program to your GPU. Though it can be pre-uploaded if you don't need it otherwise. Then run. Upload the data (hashing blob with its nonce), run the program, fetch data back. 14:12:57 Oh I see. I was thinking naively that large data set split up into individual sets especially if the result of one block verification or set is not reliant on others. 14:13:21 So you would be also IO bound shifting the data in and out of the GPU 14:13:32 It'll work, but it will be a utter waste as one set of data will be used instead of the, I dunno, maybe thousands that could have been used with no extra time. 14:14:26 Well, you could verify PoW for a whole chain I suppose. 14:14:40 At least for stuff like SHA256 and the like. 14:15:20 Yes that is what I was thinking because you have a bunch of transactions linked is there a sensible place where you could split them and then upload say thousands of chains and run that parallel on the GPU 14:15:37 It'd help for the initial sync but not after it, unless you get online every few days only. 14:16:34 That seems to be where the stalling point is in my case you get online and do the initial sync but then you have to wait. I would be interested in the churn rate in users who uninstall because the sync takes a few days.m 14:16:43 In theory you could do that (PoW and the rest separated for the whole chain). 14:16:46 I don't know if that would be an appreciable number 14:17:22 I don't know if you can tell how many installs don't complete the verification and then never come online again? 14:17:30 FWIW, by default PoW is not checked for historical blocks. So it's probably not your problem. 14:17:48 Ohhhhh 14:17:56 (You can use --fast-block-sync 0 to enable checking them all) 14:18:26 I don't know what the threshold is, but I doubt you've reached it yet. 14:19:09 You can run "top", check the third (usually) line, the one with "wa" "ni" "us" etc in it. 14:19:30 Post it here. It'll probably show what your bottleneck is. 14:19:52 will do 14:21:40 I am lost 14:22:01 I run top as in the command line top to see what's running 14:26:24 PID COMMAND %CPU TIME #TH #WQ #PORT MEM PURG CMPRS PGRP PPID STATE BOOSTS %CPU_ME %CPU_OTHRS UID FAULTS COW MSGSENT 14:26:24 53527 monerod 106.0 09:56:31 30/1 0 45 317M 0B 0B 53526 1 running *0[1] 0.00000 0.00000 501 65655928 82 4683 14:27:55 I asked for the line with wa/ni/us/sy. 14:28:10 It shows the overall utilization of your CPU. 14:29:12 Give me a sec OSX doesn't output like that of course ... 14:29:19 Ah, nvm then. 14:30:07 Its very kind of you to help thank you moneromooo 17:44:40 Soooooooo If anyone else is using macOS then I wrote a shell script to look for bottlenecks its on my GitHub repo. https://github.com/chriswilson2020/bottlenecks/ 21:21:01 as far as I know on macOS it's purely disk random IO speed 21:21:31 did you find anything else with the script?