![]() ![]() I try and stay away from the 192.168.*.* blocks for business use. In fact, to go further, any networks that are behind your VPNs, you will not want them to be commonly used for home networks. The IP block that you use for the VPN users should be almost a random block because you do not want your VPN users to have the same block as you are running on your networks. My common sense tells me that after connecting to remote LAN Client IP should be starting from 192.168.2.xxxĪ lot of VPN software/gateways will use a IP subnet to connect to, then the VPN gateway will route the traffic to the appropriate network.įor example, I use OpenVPN for and Fortigate for my VPNs. ![]() When you connect to remote LAN via VPN then shouldn't home-pc get the same three sections of IP? Since you have been doing this VPN stuff for living I would like you to ask something. Now try it with full 4K UHD disc as the source. So regardless of how long that's going to take, there WILL be a reasonable amount of time that all DE servers aren't doing anything. and make sure that your mobo supports PCIe 3.0 x4 M.2, even though realistically, ripbot workflow will never really exceed 1500 MB/s throuput, just under the max bandwidth of PCIe 2.0 x4 but otherwise get one of those Corsair MP510, or silicon power TLC drives. If money is of no object, Samsung is the way to go. when shopping around, look for reviews that do tests on large 25~50 GB file "write" tests, and the chart will show you the speed difference once those SLC cache runs out. so when doing 4K UHD workflow working with large 60~70 GB files, you're going to be counting on the raw writing speed. most TLC's raw writing speed, provided if the onboard processor is of recent version, will be around 600~800 MB/s even after it runs out of its SLC caching. go for a fast TLC drive from Corsair, Sillicon power, Samsung, and you'll be a lot happier. but just do yourself a favor, avoid all the QLC drives out there. the intel 660P 2TB drive, theoretically, if you over provision it and treat it as a 1.5TB drive, theoretically you'll always have more than 50GB of SLC caching. on a 1TB QLC drive, your SLC cache is probably gonna be about less than 20GB when it's filled at 50%. and smaller the drive, smaller the SLC casche will be. once the SLC cache run out, QLC's raw writing speed will fall below 100 MB/s sometimes 70 MB/s, that's slower than most high end 7200rpm spindle. i've tried them all and went through them all and experience all of it the hard way. QLC's raw writing speed is less than 100 MB/s. The trick with shopping for NvMe drives is look for TLC drives and avoid QLC drives at all cost. if you have the source sits on the same NvMe drive, it'll only take 3~4 mins. most 4K UHD sources take 3~4 mins total to do all that. my current 4K workflow, nothing takes longer than 4 mins for initial demux, indexing, gathering information altogether. and do yourself a favor, don't go below 1TB. i was an early adapter of NvMe for my 4K workflow, trust me, invest in a couple good NvMe drives. although Lmash is slow, on my NvMe it's still fast for demuxing, indexing etc.īut my question is, is there any real speed difference in using GPU for "decoding" method?ītw, i see a lot of folks are discussing about NvMe here. So regardless of how long that's going to take, there WILL be a reasonable amount of time that all DE servers aren't doing noticed that in the latest update, you included an option for user to select decoding method. Now, I cannot provide any final muxing, etc info at this time, as that will take a couple of days for me to get around to do that, but I WILL post my results. With the stripped mkv, it took 8:45 mins.not forgetting the it took 4:30 mins to strip out the file in the first place, so it's close'ish.Īll these figures are having the original file on a RAID-0 of 2 x Seagate 3Tb 7,200 rpm spinners, copying to an ADATA NVM'e, using a single Xeon 12c cpu. The untouched job took 12:00 mins 'til the chunks were all ready to go. Once they were queued up, it was time to see how long it took to copy the file, get the chunks created, etc, etc. ![]() Same file using FFMS2 took 0 mins to demux, and a total of 3:12 mins. Then the stripped mkv took 0 mins to demux, and a total of 3:25 mins with LSmash. Using FFMS2 it took 4:30 mins to demux, and further 3:50 mins 'til job was ready. So, chose the untouched mkv to start with, and it took 4:30 mins to demux, and a further 4:20 mins until the job creation was ready, with LSmash. I also ran it thru MKVToolnix to rip out EVERYTHING but the video, which took 4:30 mins (Raid-0 to nvme)Īlso wanted to see what difference there was between LSmash & FFMS2. I chose Harry Potter #1, which is a remux 4K, 60.7Mb/s, 84.5Gb mkv. So I have noticed a few posts about very long times to start a 4K job, so I thought I'd do a couple of tests for myself. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |