#Unlimited limits

44 messages · Page 1 of 1 (latest)

grizzled echo
#

Do we set values that are u64::MAX or u32::MAX or something else?

idle cairn
#

these are i64

#

also be careful and only override ledger_max and tx_max fields

grizzled echo
#

How about contract max fields?

#

Do we have any documentation that explains what each field is and does?

idle cairn
grizzled echo
#

I couldn't find much in CAP-46-9 or CAP-46-7.

#

Oops, I said I had looked at 7, but I had actually loaded the wrong CAP when I had thought I clicked on it. 7 does have docs in it, thanks.

idle cairn
#

you probably don't need to look past inline comments in XDR

grizzled echo
idle cairn
#

set all fields that start with tx_max to u32::MAX. set tx_max_instructions to i64::MAX. I wouldn't recommend adjusting other settings

#

I wonder how is this actually going to be used?

#

like are you going to somehow feed this to core?

grizzled echo
#

Quickstart already feeds this to core.

idle cairn
#

if so, then you'll need to do the same procedure, but for ledger_max settings

grizzled echo
#

(Thanks for the help setting that up @verbal finch)

idle cairn
#

ok, then you need to set the respective ledger max values. for some reason I thought that's limited to env config...

verbal finch
grizzled echo
#

So all ledger_max_ values to u32::MAX?

#

And ledger_max_instructions to i64::MAX?

#

What about contract_max_size_bytes?

#

And tx_memory_limit?

#

And contract_data_key_size_bytes, contract_data_entry_size_bytes?

idle cairn
#

So all ledger_max_ values to u32::MAX?
And ledger_max_instructions to i64::MAX?
yes

#

And tx_memory_limit?
yes, to u32::MAX as well

#

as for key size... I guess you could increase it, but I'm not sure it's helpful

#

I'm in general pretty skeptical about testing without limits, because it hides the issues, and entry size limits seem more fundamental than e.g. instruction or IO limit. but if you want to, you can increase both entry/contract size and key size to u32 max. I would probably still not touch the key size limit though...

grizzled echo
#

Ok yeah, agreed on key size. The unlimited limits I'm looking at now are more about runtime, not data size.

grizzled echo
#

u32::MAX?

idle cairn
#

it should be the same as contract_data_entry_size_bytes, so if you update this one, might as well update the contract size

#

FWIW we wanted to get rid of the separate contract size setting, but never got to it. they probably should stay the same

grizzled echo
#

When I use the following settings, stellar-core SIGABRTs after the upgrade is complete.

supervisor: 2023-11-03 21:12:14,307 INFO exited: stellar-core (terminated by SIGABRT; not expected)

In stderr logs:

isRepresentableAsInt64(tempResultDbl) at util/TxResource.cpp:56
backtrace unavailable
current exception: std::runtime_error("isRepresentableAsInt64(tempResultDbl)")
backtrace unavailable
# 
        {
            "contract_compute_v0": {
                "ledger_max_instructions": 9223372036854775807,
                "tx_max_instructions": 9223372036854775807,
                "fee_rate_per_instructions_increment": 100,
                "tx_memory_limit": 4294967295
            }
        },```
#

Those two max instructions lines are the only values I set to larger than u32::MAX, and they're both set to i64::MAX.

idle cairn
#

ah, interesting. tx queue tries to flood 2x the ledger resources, which makes sense for any realistic settings

grizzled echo
#

So I should set to half i64::MAX?

idle cairn
#

yeah

grizzled echo
#

Or some of the u32::MAX value sneed to be smaller?

idle cairn
#

both for tx and ledger max

#

all the resources are stored in int64s, so everything else should be fine

grizzled echo
#

Same error when the values are halved.

#

Seems okay if I quarter them.