has anyone ever used github.com/fireice-uk/xmr-stak for monero?

I got it to build on my system but it's not showing up on minexmr on my dashboard at all when running

trying to port xmrig to my main os too

riceandbeans don't bother with stak

nioc: Why do you say that?

nioc: I'm hitting a few snags in porting xmrig

nioc: So far with stak all I see is all my shares being rejected :\

riceandbeans: stak is made by someone that wants monero to fail

and AIUI has not been maintained recently although I don't really know if that is true

Well that sucks

it just copies code from xmrig

It did have some awfully similar looking functions

As someone that has spent a few hours today getting them to build on DragonFly BSD

I just download and run the binaries of xmrig cause imma ignorant

since imma ignorant I use windows

Yeah well that doesn't work when instead of being a ignorant you're a stupid and a weirdo running DragonFly BSD

:)

So, I'm trying to get it to work

CMakeFiles/xmrig.dir/src/backend/common/Workers.cpp.o:Workers.cpp:function xmrig::Workers<xmrig::CpuLaunchData>::start(std::vector<xmrig::CpuLaunchData, std::allocator<xmrig::CpuLaunchData> > const&): error: undefined reference to 'pthread_create'

CMakeFiles/xmrig.dir/src/crypto/rx/RxDataset.cpp.o:RxDataset.cpp:function xmrig::RxDataset::init(xmrig::Buffer const&, unsigned int, int): error: undefined reference to 'pthread_create'

CMakeFiles/xmrig.dir/src/crypto/rx/RxDataset.cpp.o:RxDataset.cpp:function void std::vector<std::thread, std::allocator<std::thread> >::_M_realloc_insert<void (&)(randomx_dataset*, randomx_cache*, unsigned long, unsigned long, int), randomx_dataset*&, randomx_cache*, unsigned int const&, unsigned int, int&>(__gnu_cxx::__normal_iterator<std::thread*, std::vector<std::thread, std::allocator<std::thread>

> >, void (&)(randomx_dataset*, randomx_cache*, unsigned long, unsigned long, int), randomx_dataset*&, randomx_cache*&&, unsigned int const&, unsigned int&&, int&): error: undefined reference to 'pthread_create'

CMakeFiles/xmrig.dir/src/crypto/rx/RxQueue.cpp.o:RxQueue.cpp:function xmrig::RxQueue::RxQueue(xmrig::IRxListener*): error: undefined reference to 'pthread_create'

collect2: error: ld returned 1 exit status

I think I'm going to mess with it later when I have more patience to get past this current breakage

Also trying to get powhasher built and working too

you can try in #monero-pools but few people are around at this hour and when they are there is much shitposting and trolling along with some help

So pretty much the #linux IRC channels I cut my teeth on 20 years ago.

Oh, this looks promising

I'm a sucker for Rust

Except when it makes gratuitous use of libc, and then I make sad faces

Also when they don't document that you have to use nighly rust because they depend on nightly features......like this project does....

Also, which isn't available on DragonFly...

I take it back, they do mention nightly :( I'm just stupid

How did I not know Monero was forking in a few days

bigslim[m], what monero news sources do u follow?

what monero news sources SHOULD we follow?

riceandbeans: definitely get the RSS feed of getmonero.org to your reader.

Other than that, check out the subreddit every once in a while. And take a look at the IRC/Matrix chat.

dixie__flatline[: So where is the news that it's forking in a few days?

riceandbeans: on the homepage of getmonero.org, there is an orange banner up above.

Also, the most recent 3rd blog post on the RSS feed link I posted mentions the October 17th network upgrade.

riceandbeans: revuo newsletter is a great tl;dr source of info

so network upgrade is code for fork

is it even a fork if new chain is not created and dies out after a few blocks? I don't think so

just a network upgrade

riceandbeans: well yes - Monero has had many years of typically two non-contentious hard forks every year. That seems to be slowing down a bit now - licking wounds after the ASIC-resistance forking that got a bit out of hand until RandomX came along.

riceandbeans: But as long as the forks are non-contentious, they are pretty much network upgrades - bringing privacy improvements and other enhancements to Monero.

I, for one, welcome our new orion overlord

As long as the upgrades improve privacy of monero, they do not carry the negative connotation of "hard fork" as in btc.

what's going on with monero price? it's on fire lol, some big event behind it? ( I dont follow monero much )

King is claiming his rightful spot.

about time

I always knew this coin is least of all full of shit

The only coin with an actual usage.

I updated monerod to that new release of oxygen something, yet my wallet opening is still far from speedy

maybe I am running my local daemon wrong or something

I use monero-wallet-cli and monerod

so I opent wallet and it started refresh and it gonna take some 5 mins or more, is that typical?

I depends on how many blocks you need to sync

okay

For me it's no more than a minute after 2 weeks of not opening it

and that's with older v0.16

aha

may I ask if that blockchain of yours lives on SSD?

No, my node runs on HDD, but is has 64 GB RAM, so I guess it's all cached there

maybe I need to prune it

yea that makes hell of a cache for disk reads

I could use monero-blockchain-prune tool to create a pruned copy and then tell monerod to use that?

that takes it down to about 25GB

which could be speedier? not sure how LMDB works

off it goes pruning...

not faster, just takes less space

then I guess my disks just doesnt have great random access speeds

they are lazy NAS grade drives, I just figured having bunch of them will make it suck less

ssd helps a lot

HDD's basically work like a vinyl player. Random access isn't their thing.

ok, I will prune and try on SSD to compare

pruning will take all night it seems

you might want to resync on ssd with --prune-blockchain flag

should not take longer than 6-7 hours

or just wait for your pruning to finish

that makes sense, too late now I guess

faster to resync pruned than prune full chain

gingeropolous: are you referring to news source as general news or monero? I found out about the monero fork reading cakewallet release notes last night for an update

bigslim[m]: it has been like the top post in reddit/r/monero for weeks and weeks

top / pinned

Yea haven’t been on there in a while

And not front page so Reddit’s algos killing it

Even not coming up on Twitter

I am not on the monero mailing list though, or wownero. Totally forgot about that fork. Busy weekend

what does locked mean in show_transfers output? on 3rd column

bigslim[m]: how would you suggest to announce the hardfork?

almost every second tweet contains the info, there is a huge banner on the website, mailing list, reddit, etc

are we missing something?

a marching band

skywriting

Ad during superbowl

a formation of drones writing it in RGB pixels into the sky

banner on monero.org website?

getmonero.org

via an emergency SMS direct alert system

selsta: I think you guys do great. Honestly I thought I had monero on git followed for releases. Apparently I wasn’t there either.

Yup

it is written there but it does not stand out that much

I’ll get stuff updated tonight now that I have a little free time

Going to see how monero syncs on fiber now

I'm guessing, if you have a reasonable ssd, that the limitation will be CPU clock

Inge-: how long did it take you again to sync?

<5 hours on high end hw/ssd/300mbps internet connection

you know what’s weird, it took me less than 6 hours on a $10 VPS with rather low end hardware (but with SSD)

so I wonder what the bottleneck is

yeah I don't think there was a huge diff between an i7-8650u and a threadripper 3970x

definitely puzzling. I've done pretty fast syncs over a LAN

hyc: define pretty fast?

but I see a lot of time where network is idle

yea resources are barely used during sync

and also time where CPU is idle

disk access?

sometimes, but not every time

talking about checkpoint fast sync, resources get used a lot after checkpoints

I'd make a wild guess that paralellization is somewhat limited ( I guess you could do all tx in a block in parallel - but need to complete one block before verifying the next) - and you need the random access to all inputs ...

for long can a transfer of coins be stuck? mine is 3 hours already I think

horsepatat: simple mode GUI?

monero-wallet-cli

transfers are locked for 10 blocks. Should be... 20 minutes on average. Unless the sender set a lock time, in which case it's whatever the sender set (min 20 blocks).

I didnt set no lock time

Try: show_transfer TXID in the wallet

It should tell you if it's locked, and for how much time.

that timestamp nearby word locked?

Seemed better not to put it elsewhere, yes.

it says pending, out and today's date, seeminly when I sent it

Pending means it's not mined yet.

So it might be it's only in your txpool, but the network did not learn about it yet. Fixed in git.

the receivers wallet says pool, in locked and same date

You can do, in monerod: relay_tx TXID

Both using hte same daemon ?

yea

literally

Is hte tx visible in an explorer ?

If not, it's likely what I just said, and you need to relay the tx as it failed to propagate to the network.

doesnt seem so

that would make sense then

selsta: are you including 6875 in that coming release ?

yes

THanks :)

wait, that command is for monerod, not wallet

once vtnerd approved it

relay_tx is monerod, show_transfer for the wallet.

I run it non interactive

so I will restart it interactive to do just that

can't all those commands be sent via RPC as well?

issued that command

seems it froze

selsta: 5hrs from a full sync, not fast sync or pruning?

Last time I did with same hardware on cable it took me 6 days to full sync

"monerod relay_tx TXID" will work.,

1950x with 32gb ram

HDD ?

M.2

Sabrent rocket

Is that a HDD ? :)

did you add `--fast-block-sync=0` ?

But apparently was getting 25Mbps or less average

I mean the spinning type, as opposed to flash.

No just straight ./monerod

From 0

The only hdd I have are for media server

6 days sounds extremely long for SSD, when was that?

it should take you ~6 hours to sync up now

maybe even less with your hardware

Iirc 14.0

OK. Then run top, and see what's taking time, if anything. user, kernel, I/O (wa). Third line in top's output IIRC.

I have noticed standard sync with like 30k blocks takes maybe 20-30min now as opposed to 3hours

Windows :)

fuck windows, use linux!

Lol

It's got a task manager somewhere that shows similar info.

It’s my do all server. Vms, dev, Plex, other

Monerod always sucks up resources but never more than maybe 12gb ram and 30-40% cpu

I’ll try here when I get a chance to update it and start. I’ll let you know. Need to update wownero too. Bummer I missed the fork

cmake is not possible to work with ndk!

we must turn to build.sh

takel: when was the last time build.sh worked for you?

i did git for 2019 november but still didnt work so is before

more than 1 year before

the bad is that lot of good things that were added wont play now

oh wow. the Sarang vacation CCS is 5 xmr away from being fully funded in 4 days.

last chance to contribute guys!!!!!

and CLSAG goes live in 4 days \o/

Get your moneroj on there and let’s try to make this the highest contributor count CCS yet 😉

a 26k$ vacation? that's alot of cocain and hookers

well deserved

Am I the only peron here that doesn't twitter, facebook, or reddit? I'll make sure I have the getmonero rss feed though, hopefully that's enough. Just, every time I hear fork I think of crap like BTC -> LTC or BTC -> BTC Cash

riceandbeans: the getmonero feed will be enough. There is also the mailing list for important updates. I think we cover more or less everything, don't know what else we could add

Eh, I mean, sometimes I miss things here, it's life

jonathancross, I think there is some bug with dandelion which might be causing that

jonathancross: Can you be more specific with sync speed? Daemon sync from block 0?

<thrmo "jonf3n, I think there is some bu"> Hmmm... interesting. I'd assumed Dandelion++ was only used for transaction broadcast between peers. Could it affect block download as well?

<selsta "jonf3n: Can you be more specific"> No, I just needed to sync the most recent few thousand blocks.

You have to consider the large increase in daily transactions.

<selsta "You have to consider the large i"> Yes. But the bandwidth just was not being used.

yes, because bottleneck is verification not network speed

CPU / Ram / disk also not being used.

Was this on HDD or SSD?

It none is used, it's possibly waiting on data from a peer. If that peer's busy, it might wait a bit before sending. Can't really tell with just "it is slow".

It is a HDD. But only `100 - 300 KB/s` being used. I tested the disk speed during the sync and still got `17.1 MB/s` -- so there was extra disk bandwidth that was not being used.

It's seek time that matters, not contiguous r/w speed.

yes, HDD will always be extremely slow during verification.

speaking on that is there a meaningful difference between a sata ssd and a nvme one?

<moneromooo "It's seek time that matters, not"> Ah, I'd assumed seek time was important when constructing a TX, but not so important when getting blocks from the network.

I'll test that next time if issue shows up again.

jonathancross: disk queue length is indicative (while transfers/sec will be very low for random reads on a HDD) and if any single cpu core is pinned at 100% (overall CPU utilization could be very low as there is a limit to how parallelizable the workload is))

<thrmo "speaking on that is there a mean"> Seek time for nvme is generally 10x faster than SATA III SSD. So...

<Inge- "jonf3n: disk queue length is ind"> Good point.

Is there something in Dandelion++ that could also slow down block download from peers?

Not that I can think of.

moneromooo: Thanks. I thought so.

moneromooo: And per Inge-'s suggestion, that multiple cores might not be utilized for verification. Does that sound reasonable to you?

Inge- said just one line AFAICT. I don't know much about disk queue so can't say. It doens't sound bonkers at least :)

hm, currently the blockchainDB is protected by a single criticalSection

so perhaps that limits concurrency in tx verification

Not really. The lock is taken for a chunk of 20 blocks.

But the parallel part is low level, it's not "verify 20 blockjs in 20 threads", it's "run this same low level routine N times".

hmmm

hard to guess whether "verify 20 blocks in 20 threads" would be better

I suspect it could be though

far less overhead in running N copies of a serial job than trying to parallelize all the components of a single job

of course in the latter approach, if you have more than 20 cores you need to increase the syncblock size

It cannot always be though. If block 19 requires block 9, say.

Anyway, it's a hell of a lot faster than it used to, but people always forget I guess.

At some point I just think... not again...

one can never have enough speed

especially since the blockchain only ever grows

The thing I'd like is a rw lock in the Blockchain class now.

Without rewriting random things like the previous patch did.

Wallet syncnug at the same time as blockchain syncing -> very slow.

yeah, the whole locking stratey is garbage

s/garbage/safe/ :)

well, LMDB is N-readers+1-writer and perfectly safe

better than rwlocks

<hyc "so perhaps that limits concurren"> My system is old (4 core Xeon), but wouldn't others have complained loudly if verification only used a single core?

Sure, not really my point though. You have something super complicated and safe too.

Oh, they did, you can be certain about it.

It used to.

I mean you have something 100% memory safe in hand coded asm too. It's just much harder.

Well, for, I dunno, a std::multimap usage, say.

jonathancross: you probably would never have noticed. I have 8 cores and pretty much never see more than 4 cores used

there's definitely something artificially limiting throughput

I just don't know how to pinpoint what it is

cpu firmware

<takel "cpu firmware"> Could test if that is a bottleneck using a ramdisk.

the issue is firmware closed source

this is the real issue

they can do whatever and u dont know

To be fair I didn't mean to indicate it was single core, just that the number of cores that can be utilized are limited. I would expect parallel verification of transactions is possible, while parallel validation of blocks is more difficult (although maybe possible to verify with assumptions, and do a second pass to check block hashes are correct once they have all been calculated

Hey, I want to setup a monero full node at home.

However, first I want to really make sure that my home network router settings are watertight and can stand against a rogue pentester (i.e., hacker) in my neighborhood.

Anybody here have some nice internet tutorials on that?

Will activating "Enable displaying balance in other currencies" send my balance to a website, or just request the current price of Monero and convert the values locally?

moneromooo: 2.19mil blocks left to sync. Let’s see how this goes

6.5yrs behind lol

Also I heard that Monero is doing a hard fork, I'm on version 0.17.0.1, do I need to do anything?

No, though updating to 0.17.0.whatevercomessoon is probably a good idea. Either way, you should be fine for the fork.

oh wow

Wow three hours in and 50% blockchain synced, 52%

Only a million blocks left

This is where it gets rough with ring CT

bigslim[m]: yeah first 60-75% are a breeze ...

Copenhagen_Bram: I believe it only looks up exchange rate, not sending any other info

<Inge-> Copenhagen_Bram: I believe it only looks up exchange rate, not sending any other info

And if I have the proxy set to 127.0.0.1:9050, it looks up the exchange rate over Tor, right?

Copenhagen_Bram: yes

cool

How come I keep getting "Maximum number of clients reached" for every keystroke I make in the Monero window?

Never seen that message.

Where does it print that?